Re: Re: Mercurial repo cloning

Hi Christian,

Christian Lohmaier wrote:
> Hi Guido, *,
> 
> On Sun, Aug 30, 2009 at 1:17 AM, Guido Ostkamp<[email protected]> wrote:
>> On Sat, 29 Aug 2009, Bjoern Michaelsen wrote:
>>
>> Furthermore I strongly believe that using 'clone' might be a lot slower than
>> downloading a binary file (might it be a 'bundle' or a 'tarball') over
>> 'http' or 'ftp' with a modern download assistant using multiple connection
>> at the same time.
> 
> download cannot be faster than your physical connection - and if
> you're afraid of connection losses, then your line is probably not
> that fast...
> 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)
> 
>> 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.
> 
> Better create a real clone on some machine with good connection and
> copy from there..
> (or ask someone fur a bundle/archive of the whole repo)
> 
>> The only problem is that one needs the long format changeset id's for that.
> 
> You can use the tags as well - starting from DEV300_m31 in the pilot repo.
> 
>> Looking at SVN repo I had originally expected much more and huge changesets
>> but it seems DEV300 does not to contain the complete history.
> 
> see the wiki for details of what it contains.
> 
>> Even if looking at the CWS, it appears clear that getting a copy of a CWS
>> also requires special treatment in order to not download everything again.
> 
> No, you pull from the cws and you're done. of course if you create a
> new clone each time you want to build, you have to redownload.
> 
>> This means, 'clone' is not an option here, but one should 'clone' or 'cp' an
>> already existing copy of DEV300 locally, and then 'hg pull' that CWS into
>> the copy; otherwise everything is transferred again and much disk space is
>> wasted.
> 
> 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.
> 
> 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.
> 
> That's what I use for tinderbox (well, those who got an hg client installed :-)
>     my $changeset = `hg id $sourceurl`;
>     chomp $changeset;
>     print "pulling...\n";
>     system('hg','--time','-v','--cwd',$hgrepodir,'pull', $sourceurl)
> == 0 or die "pulling failed! $!";
>     print "setting up buildtree...\n";
>     system('hg','--time','-v','--cwd',$hgrepodir,'archive','-r',$changeset,$shadowdir)
> == 0 or die "creating builddir failed $!";
> 
> getting the tip-changeset of the cws you're pulling from is necessary
> because of the abovementioned behaviour of hg pull.
> Of course if you want to work on the tree, instead of using archive,
> you would use clone and update.
> ("archive -r "is faster than "clone -U, followed by update -r" and way
> faster than "clone -r")

I haven't thought about using 'archive -r' for "build-only" working
trees (build-bots, tinderboxes and the windows build-machines called
"feed-me" which we use here). Good point!

> 
> 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.
> 

Regards,
  Heiner