Re: Re: Mercurial repo cloning

Hi Christian,

On Sun, 30 Aug 2009, Christian Lohmaier wrote:
> download cannot be faster than your physical connection

Sure. But if something on the way or on the server limits transfer, 
multiple connections can speed it up.

> you're afraid of connection losses, then your line is probably not that 
> fast...

I have DSL 3000 here. That is slow, and the longer the transfer takes, the 
more likely it is that the connection will get a hickup.

> cloning via hg directly is not that bad IMHO. (Yes, if your connection 
> is flakey, you want something that can be resumed, but that by itself 
> doesn't make a tarball more suitable)

I can't see why a tarball should not be suitable here - of course any 
other single file will do as well, e.g. a 'hg bundle' output, the transfer 
just has to be resumable. However my impression was that 'hg bundle' takes 
much more time to generate and unpack as a simple tarball.

A 'bundle' only makes sense when you need to update an already existing 
non-empty repo with a bunch of changesets; in this case tarballs of course 
cannot be used anymore.

>> One can initialize an emtpy repo and then use a sequence of 'hg pull -r 
>> <rev>' commands where the <rev> is then increased by a lower number of 
>> changesets.
>
> /that/ is inefficient and takes longer and will transfer more data than 
> a real clone.

Might be, but it's the only safe way as long as there is no resumable 
single file transfer available.

> You can use the tags as well - starting from DEV300_m31 in the pilot 
> repo.

Good idea.

> Yes, definitely you should base your cws on a locally available clone of 
> the repo. Not sure where you got the idea that cloning a cws is a good 
> thing to do.

Well, most likely because it's the Mercurial standard way to handle things 
you've got those separate CWS repos here (with Git you would probably only 
have one). A beginner could easily fall into this pit and 'clone' the DEV 
and some CWS separately.

> The only thing to pay attention to is that a hg pull doesn't switch the 
> default tree to the location/version you pulled from if there were no 
> changes.

Right. At least one can 'hg update' when it is known which CWS is at which 
head.

> If working on such a clone, the only thing to remember is: specify tip 
> as your revision to hg push, otherwise it would push the changesets from 
> all the other cws and the main-repo in addition to your changes to the 
> cws.

Yep. There should be a switch to change the 'push' default behaviour so 
that only the branch one is currently on is pushed.

Regards

Guido