Hi Heiner,
I've checked this one out. Seems to be a consequence of the hg
developers decision to only ever append to a "revlog" (hg's basic
storage unit) and some other design decisions, Makes the storage quite
stable I assume at the cost of space inefficiency. A pity I think.
the decision to only 'append' to revlog is not the reason.
I've already discussed this with the Mercurial guru's 2 years ago and the
outcome was that for each move, a new revlog is created with at least one
full revision and a backpointer to the original location of the file.
Somebody supposed they wanted to save some disk seeks (by avoiding looking
at the older different history file which would be necessary in order to
process deltas when they did not have that initial full revision).
The Mercurial Guru's believe in "disk space is cheap".
In my mind this is the one major point where Mercurial went the wrong way,
and it leads to more problems.
Not being an official tester, I didn't know you were collecting Mercurial
feedback for a report, so the following did not make it into that report:
Mercurial lacks support for cheap inline feature branching and you always
have to clone the whole repo (note that I do not mean 'named branches' in
a single repo which Mercurial supports because those cannot be removed
from history anymore and they also would be pushed if you push from the
repo).
This costs tons of additional disk space and CPU time because you have to
rebuild everything from the ground up (object files, executables,
libraries etc.) as a feature branch (you call it CWS) always means a
separate new directory tree in Mercurial.
With Git you can switch from one branch to another one and - provided your
makefile dependencies are correctly setup - you just need to recompile and
relink the affected parts (because all changed files get current date on
the switch of branches), in other words you don't need the generated
object files, libraries and so forth n-times (though you can have it
seperately as in Mercurial, if you really wish).
Even the repo history must be duplicated in Mercurial if the clone is not
to be placed on the same physical filesystem because the hardlinks don't
work in this case (which requires n times the storage).
Furthermore you would possibly need multiple repository clones to keep
track of several remote branches in Mercurial.
With Git you can follow multiple remote branches in just one repo, you can
setup cheap branches which can be completely removed from history (when
everything is integrated upstream) and you can have one base-repo
somewhere in your filesystem and multiple clones elsewhere which just
reference the base repo without copying it.
Regards
Guido
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
