Le 04/05/2011 16:50, Oliver Tappe a écrit :
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.Hi guys, On 2011-05-04 at 16:48:29 [+0200], Axel Dörfler<axeld@xxxxxxxxxxxxxxxx> wrote: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 incompatible. 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.