I'm using network repositories in Windows all the time. They work fine with
darcs 1.0.9, but darcs 2.2.0 and earlier versions too choke on them. Here's the
scoop:

1. change into local repository, like C:\TD2
2. pull from remote repository, like: darcs pull -a //kkh/TD2

RESULT:
Stack space overflow, current size 8388608 bytes.
Use `RTS +Ksize' to increase it.

Increasing does not fix the situation, obviously.

I have tested this with darcs 2.2.0 hashed repositories, as well as with old
legacy darcs 1.0.9 repositories using darcs 2.2.0 executable. 

If darcs is handling remote computers differently, this should be a code
shrinking fix.

On Tue, Feb 10, 2009 at 9:38 PM, Kari Hoijarvi <bugs@darcs.net> wrote:
>
> New submission from Kari Hoijarvi <hoijarvi@me.wustl.edu>:
>
> I'm using network repositories in Windows all the time. They work fine with
> darcs 1.0.9, but darcs 2.2.0 and earlier versions too choke on them. Here's the
> scoop:
>
> 1. change into local repository, like C:\TD2
> 2. pull from remote repository, like: darcs pull -a //kkh/TD2

I tried the same steps you wrote about, and it works for me (using
darcs 2.2.0-win1 binary from darcs.net).
Are you using that binary? Which kind of repository are you using?
(darcs2, hashed, darcs1)

Can you try with a new repository made with darcs init?

Salvatore

I'm using http://homepage.mac.com/kirby81_it/darcs/darcs-2.2.0-win1.zip

I have my TD2 repository 7-zipped here: http://webapps.datafed.net/stock/TD2.7z 

It's only 8 MB, nothing huge.

I's in my 64 bit XP machine, but I don't think this machine matters since darcs
is not running there.

I have tried to pull from 2003 server and 2000 workstation

md TD2
cd TD2
darcs init --hashed
darcs pull //kkh/TD2

Same result. I can't pull my other medium sized darcs-1 repositories either.

Can you try it again using this executable (it requires the dll
included in your previous download):
http://homepage.mac.com/kirby81_it/darcs/darcs-i18n.zip

It is the same version, but compiled with GHC 6.8.3.

"The procedure entry point EVP_Cipher could not be located in the dynamic link
lybrary libeay32.dll"

I just verified, that my downloaded darcs version is right. Could you please put
the dll's available, I'll check it right away.

On Wed, Feb 11, 2009 at 5:38 PM, Kari Hoijarvi <bugs@darcs.net> wrote:
>
> Kari Hoijarvi <hoijarvi@me.wustl.edu> added the comment:
>
> "The procedure entry point EVP_Cipher could not be located in the dynamic link
> lybrary libeay32.dll"
>
> I just verified, that my downloaded darcs version is right. Could you please put
> the dll's available, I'll check it right away.

You have to put the newly downloaded darcs.exe in the same directory
of the previous one (2.2.0-win1 the dll are the same).

You're right, it tried to use the one in C:\WINDOWS\SysWOW64

But the problem is still there. After one minute:

Stack space overflow: current size 8388608 bytes.
Use `+RTS -Ksize' to increase it.

If you can't reproduce it with my TD2 repository, I could run a tracing version
here.

Now I think I have found a good clue.

The TD2 repository cannot be pulled between any of my machines at work, but
between two computers at home darcs works just fine.

Then one day I tried to pull at work from a machine that was turned off. Same error!

So try this with darcs 2 in windows, I haven't tested unix variants:

c:\TD2>darcs2 pull //non/sense/
Stack space overflow: current size 8388608 bytes.
Use `+RTS -Ksize' to increase it.

So darcs has a problem detecting dead computers, and I assume somehow the
network at work responds in a way that darcs considers remote computers dead. 

darcs 1.0.9 responds
darcs failed:  Not a repository: //non/sense/ (//non/sense/_darcs/inventory: ope
nBinaryFile: does not exist (No such file or directory))

Not a pretty message, but correct.

The following patch updated the status of issue1351 to be resolved:

* Resolve issue1351: fix repository path handling on Windows. 
Ignore-this: c2304776ba44dde603b7627b262bcb08

ioAbsolute is supposing that takeDirectory will eventually lead to an
existing directory. This is true on Posix, where it will lead to "/",
but not on Windows, where it could lead to a non-existing unit or an UNC
reference to a non-existing server. This patch fixes this assumption,
avoiding an infinite recursion.