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")
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.
ciao
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
