At Fri, 12 Jun 2020 09:50:27 +0200, Andreas Kusalananda Kähäri <andreas.kahari%abc.se@localhost> wrote: Subject: Re: "hg clone https://anonhg.netbsd.org/src/"; still aborts, but... > > Well, you're asking to fetch all the history for all the sources to an > actively developed operating system project running since at least 1993 > (27 years). But of course. That's the point. The suggestion earlier on this list (netbsd-users) was to do exactly: hg clone https://anonhg.netbsd.org/src/ a) That doesn't actually work at the moment (and hasn't, ever?). b) Even when you work around the problem, it's TERRIBLY slow. Arguably it is unusably slow. > With git, you can use --depth=1 when cloning to create a shallow clone. > This would limit the amount of data fetched. I imagine Mercurial has > some similar option (but I don't really know). Yes, but the intent of comparison with Git is to do the same as with HG, i.e. in the same normal way that most DVCS-using projects expect users to fetch their sources -- i.e. fetch _all_ the history _all_ the time. From this initial experience with HG in such a "large" project, it seems the problem isn't really with the amount of data fetched, but rather with the amount of processing required to convert it from a "bundle" format back into an on-disk repository format, plus some unexplained amount of extra time it takes to extract the files from an HG repository when doing the initial checkout (since obviously the amount of data output to the filesystem must be identical between the two checkouts). That's why I asked if there's a more efficient mode of supplying whatever data is needed for an HG clone to take place (i.e. instead of supplying it in the "bundle" format). At the moment it looks like Git is going to finish about 3.3 times as fast while suffering equivalent amounts of background activity occurring separately on my NFS server, i.e. in under 1.5hrs compared to HG's 5hrs. Once I can get my fastest server rebooted I'll be able to compare both without having competing file server activity, though ultimately what I've done this evening is probably a more fair test in an environment that might better mimic what other users will do. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgp6iBsMuvj0a.pgp
Description: OpenPGP Digital Signature