[haiku-development] Re: Git/Hg: some speed tests

  • From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 04 May 2011 17:50:30 +0200

Hi guys,

On 2011-05-04 at 16:48:29 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> 
> Niels Sascha Reedijk <niels.reedijk@xxxxxxxxx> wrote:
> > === Checkout on Haiku ===
> Thanks for all the tests! Judging from the syntax alone I would prefer
> hg :-)
> Does all those commands work on Haiku as well?
> I don't find the complete checkout times that important, how does
> rebasing the local repository to a more recent revision look like?
> How fast is switching between branches?
> How fast is creating a new branch?
> How fast is merging a branch?

While interesting, all of these speed tests are pretty moot (as is the 
vote!), unless someone can help me solve the following problem:

We intend to use incremental global revision IDs in order to be able to 
identify revisions across different repositories, right? 

Mercurial does have support for revision-IDs, but these are not at all kept 
identical across different repositories. Whenever you pull from the 
upstream repo, the revision-IDs will change when you have committed local 
changes to your repo. So how does one find the local revision corresponding 
to a specific revision ID in the central repo? I have thought about this 
for a while but have not yet been able to come up with a good solution.

One could avoid the problem by always rebasing when pulling, but that's not 
the default in Mercurial. On top of that, the whole concept collapses when 
there are local branches in the repository (the branching via bookmarks 
concept that was suggested we use for Mercurial). If there are branches in 
the repository that are not on the server, the revision IDs will be 

Branching-via-bookmarks and consistent revision IDs are simply 
incompatible, so we have to come up with some other means to mark global 
revision with an ID in Mercurial. With git, the proof-of-concept 
implementation has been to use lightweight tags for that, which will be 
pulled/pushed together with the changesets. From what I saw during my 
tests, that works. Mercurial does have tags, but they either are not shared 
(i.e. won't be pulled/pushed) or they are version controlled (i.e. setting 
a tag will trigger another changeset). I don't know about you, but I 
wouldn't like every other commit to be one just adding a tag.

If someone has an idea how to create consistent revision IDs in Mercurial, 
please speak up, as otherwise, IMO, Mercurial won't do, no matter the vote.

> And finally, does hg support updating the local repository without
> (temporarily) throw away my local changes?
> As far as I understand, that takes 3-4 commands with git which I find
> very annoying (git stash, git rebase, git stash apply[, git stash
> clear]) -- or is that only relevant when working with SVN as a source
> repository?

Hm, I suppose a 'git rebase' should suffice to bring your local branch up 
to date (and re-apply your local changes at the end). If you have 
*uncommitted* local changes, too, then you need to store those with git 
stash, that's right. 
Mercurial does have rebase support, too, but it works just like git's - it 
just deals with committed changes - any uncommitted changes would have to 
be stored beforehand or will get lost during the rebase.


Other related posts: