Hi Guido, please see my comments inline:
Guido Ostkamp wrote: > 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). This means if files are moved than not all the old history is copied, only the last revision (which is the first under the new name)? OK, that's better than what I feared :-) > > 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: I've collected feedback not only from "official" participants but from anyone who came along with an problem or an opinion, if it was relevant in the context of OOo going mercurial. You might have noticed that I mentioned the storage inefficiency reported by you in my 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). Mercurial might not have cheap inline branches but it has bookmarks which IMHO fulfill exactly the same purpose for which would git users use their inline branches. Bookmarks are a local thing and do not cost any relevant additional storages. As Björn mentioned, Mercurial does have cheap inline branches, they don't just have a name by default. Just create a new head. With bookmark you can assign a local name to that head. > > 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. All this is not an issue anymore with bookmarks. > > 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. I'm not sure if multiple remote branches in one repository are worth the effort, but for this case we could use "named branches". Tschau, Heiner -- Jens-Heiner Rechtien [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
