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

  • From: Adrien Destugues <pulkomandy@xxxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 04 May 2011 18:25:36 +0100

Le 04/05/2011 16:50, Oliver Tappe a écrit :
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.

If there is something like svn commit hooks, it may be possible to increment a revision id in a version.h file. Then, we can include that in AboutSystem (or somewhere else) to get it available in the built Haiku. Would that work ? If the hook is set up on our central repository, it is the only one to handle versions.


Other related posts: