Fwd: Re: Revision control

[Arne Babenhauserheide]

Am Mittwoch 04 Juni 2008 07:33:10 schrieb Ivan Shmakov:
>  > Mercurial offers the same, for GNU/Linux and Windows.
>
>       Indeed.
>
>       I assume that it will break the hard link as soon as a change is
>       committed for the file?

Yes (I just tested it). 

Result: As soon as you commit a change, the history needs to be stored in the 
cloned repository, too, while I assume that git would only store the new 
data. 

This is bound to take a little bit more space, especially for big files which 
are changed very often, but having the changes for files data stored in a 
structure similar to the tracked files takes advantage of disk and filesystem 
capabilities when pulling in many changes by reducing seeks. 

It's speed vs size, I think. 

Besides: Is there some easy way to have a shared push repository to do garbage 
collection automatically? 

>  >> Also, it's possible to use a related local repository as an
>  >> additional source for changesets while cloning a remote repository
>  >> over the network, allowing for the bandwidth saving as well.
>  >
>  > Did you test the efficiency (and how often it can be used)?
> 
>       I assume that the efficiency is comparable to that of the
>       hardlinked repositories case.  

That sounds useful. 

I can think of at least one way to do something similar with Mercurial, but I 
don't yet know, if it has already been done. 

After all, the repositories are related and most changesets will be the same, 
and Mercurial identifies changesets absolutely, just like git does, so it is 
easily possible to find out, which parts of the repositories are the same (or 
more advanced stuff). 

>  >> Also, as Mercurial records only the parents of the revisions (and
>  >> not all their ancestors), it should become challenging to implement
>  >> the ``cherry-picking'' feature.  (Though I don't
>  >
>  > There's a Google Summer of Code project doing that.
>  >
>  > And Mercurial knows the parents of parents, so it knows the whole
>  > history step by step. It avoids keeping duplicate data that way.
>
>       That's the point.
>
>       Consider, for example, branches A and B, containing revisions
>       A.1 .. A.3 and B.1 .. B.3, so that A.1 and B.1 are direct
>       descenders of some revision C.1.  Then, one wants to merge the
>       change B.2 (the change between B.1 and B.2) into the branch A
>       (as A.4.)  There, one cannot simply use A.3 and B.2 as the
>       parents for A.4, since that would imply that B.1 is also an
>       ancestor of A.4.  But the whole point of cherry-picking is that
>       it /doesn't/ become one.
>
>       Of course, one may produce a diff (B.1 -> B.2) and then apply it
>       to A.3, making A.4, but it won't be tracked by Mercurial.  (Thus
>       leaving the possibility for applying a change twice, or not
>       applying a change at all.)

I see the point. 

I don't know the Mercurial repository format well enough to say, if specifying 
that a history goes back only a few steps (or some different solution to 
archieve the same) is possible. 

I'm interested in how they are going to tackle that in the Summer of Code 
project. 

I didn't find information about the way they want to do it in the short 
description (and I don't have the time to investigate right now, so I'll wait 
until the rebase plugin is finished (or at least developed and documented far 
enough) to see if it meets these needs. 
- http://code.google.com/soc/2008/hg/appinfo.html?csaid=EC7D811E53CA98EF

>  > As a plus, I like the Mercurial documentation very much. Even
>  > advanced stuff can be found quickly.
>
>       I've never had any serious need for documentation for Mercurial,
>       but (unfortunately) I could easily believe that it's better than
>       the one supplied with Git.

Mercurial has the hgbook, for example, which not only documents how you can do 
things, but often also, why things where done the way they were done. 

For example I used it to write my hooks to upload the tracked website with 
lftp automatically after pushing. 
- site: http://infinite-hands.draketo.de/
- repository: http://freehg.org/u/ArneBab/infinite-hands/
- hg and lftp guide (german): 
http://draketo.de/deutsch/freie-software/licht/webseiten-aktualisieren-mit-mercurial-und-lftp

It also is a pretty interesting read on its own :) 

- http://hgbook.red-bean.com/

Best wishes, 
Arne

signature.asc
Description: This is a digitally signed message part.