[haiku-development] Re: Proposal: Moving away from Subversion

  • From: Simon Taylor <simontaylor1@xxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 23 Jun 2010 10:56:47 +0100

Axel Dörfler wrote:
> Ryan Leavengood <leavengood@xxxxxxxxx> wrote:
>> On Tue, Jun 22, 2010 at 4:55 PM, Ryan Leavengood <leavengood@xxxxxxxxx> 
>>> wrote:
>>> Could someone explain how a distributed VCS like Mercurial can
>>> possibly use monotonically increasing revision numbers?
> [...]
>> So my point is, we would need to use a big hex number with Mercurial
>> as well when making releases and doing bug reports, so I don't think
>> that is a valid reason to disqualify Git. Sorry, but unless we stick
>> with Subversion we will need to move past revision numbers.
> 
> Not at all. Since we will continue to have a central repository, we 
> will continue to have stable communicable revision numbers. For 
> everything outside the central repository, we'd have to use hash values, 
> but that doesn't matter.

I agree that revision numbers make a lot of sense when there is a
central repository. I looked into this a while ago, and bazaar seemed to
be the only VCS that natively supported the idea of a central tree.
Revision numbers were based on that one (and I think take the form
trunk-rev.clone-id.revision-id or similar for commits to the non-central
repositories). The other neat thing is that the central repo was always
"valid", in that any merge conflicts had to be fixed in the local tree
before being pushed. Finally it also asked for confirmation for all
files being merged, even if the automatic merge didn't throw up any
conflicts. That seems like a good thing as just because a merge works
when treating the text as text doesn't mean the code is still valid
(maybe assumptions changed in other parts of the code of something).

After all that I ended up using hg because it has better tool support
(the mercurial eclipse plugin is very good).

Simon

Other related posts: