Hello Manoj Manoj Gudi wrote: > Hey! > I must say that having git learnt first, darcs seems very simple and > intuitive to use, really like it!
Thanks! > and now the but: > > I am trying to commit a new log file (size 20Mb), `darcs record` works > fine, however `darcs push` hangs after asking for credentials.. > > the repository is hosted on hub.darcs.net; I already checked network and > credentials, I can push a small file and it works fine.. > > When I try the same thing on an another machine, I get output as > > *killedShall I push this patch? (1/1) [ynW...], or ? for more options: > yKilled* > I understand that log file shouldn't be version controlled, well, at least > not like this.. but I really want to try this cause this fits my use-case > (incrementally versioning changes in logs) > > Any ideas? You hit a long-standing weak spot of Darcs: transmitting large files can take a long time. The good news is that it /will/ finish. This is not an exponential explosion like with the old "conflict wars", where you could wait until the universe ends, it just takes longer than one would expect. Unfortunately there is no indication of progress, even with --debug --verbose. So, don't despair, just give it more time ;-) However, we should definitely fix this! With a simple test example I can reproduce this easily. Investigating a bit (using the HEAD and --debug --verbose), I found this: [...lots of stuff that initially scrolles by...] ssh frank...@tiber.acc.bessy.de darcs apply --all --debug --repodir '/tmp/large' Beginning identifying repository . Done identifying repository . Identified darcs-2 repo: /tmp/large and then it seems to hang for about 6 minutes(!). When it finally continues, I get: Beginning defining set of chosen patches Done defining set of chosen patches Beginning merging them Done merging them Beginning examining patches for conflicts Done examining patches for conflicts Checking for conflicts... Announcing conflicts... Checking for unrecorded conflicts... Beginning identifying repository . Done identifying repository . Reading working directory... Working out conflicts in actual working directory... Applying patches to the local directories... Adding patches to inventory... Writing hash file to patches In fetchFileUsingCachePrivate I'm going manually getting 0001038242- ec7da30a47e5c1b4bcf79b1a144aa629301bc65ff6d3abc91f204d6b499d4e38 from /home/franksen/.darcs/cache/patches/0001038242- ec7da30a47e5c1b4bcf79b1a144aa629301bc65ff6d3abc91f204d6b499d4e38 No sources from which to fetch file `0001038242- ec7da30a47e5c1b4bcf79b1a144aa629301bc65ff6d3abc91f204d6b499d4e38' thisrepo:/tmp/large cache:/home/franksen/.cache/darcs readonly:/home/franksen/.darcs/cache etc etc and it finishes pretty soon afterwards. During the long time darcs is silent, cpu and memory usage by the remote Darcs is negligable (as reported by top). The local darcs process seems to be quite busy initially, but that drops down to similar levels pretty soon. This lets me guess it is a matter of the underlying file transfer being less than optimal. Question for the experts: Where in the code is the file transfer implemented? What mechanism is used? Cheers Ben -- "Make it so they have to reboot after every typo." -- Scott Adams _______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
