[haiku-development] Re: Finally deciding on a new source control system for Haiku

  • From: Niels Sascha Reedijk <niels.reedijk@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Mon, 2 May 2011 12:33:58 +0200

Hi,

2011/5/2 Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
> Niels Sascha Reedijk<niels.reedijk@xxxxxxxxx> wrote:
>> But most of the errors for hg were a file permission problem,
>> indicating that either Haiku's file system, the POSIX part of Haiku,
>> or Python's glue to Haiku, or the hg test suite has a flaw. (The
>> latter is not unlikely because of the way the tests work).
>
> However we put it, it's fixable, anyway :-)
>
>> So in this sense it seems to me that the choice will be less 'clear'
>> than envisioned. It really comes down to taste.
>
> I think the biggest hg drawback is the lack of hard link support in BFS; 
> since the rest is mostly a matter of taste, I would argue that git would be 
> the better choice then.
> However, with tools like git-svn working perfectly fine, and our main 
> repository working pretty much how SVN works, what is the exact motivation to 
> switch? We can already have developer branches at github if we want to, and 
> everyone can already use git locally now. I would definitely not want to 
> sacrifice our current Trac integration for git on the server.

There is a 'third' way here. I already wrote a proof-of-concept that
allows pushing from hg to svn. This is not a lossless push, as the
different commits will be collated into one in the svn world.  This
should be able to be ported to git as well. The only issue is locking,
but that is definitely solvable since all the trees live on the same
disk. The advantage would be that the subversion repository can remain
our central line of development. In parallel different hg/git trees
can live, exchange changesets, and live as breeding ground for
testing, or for parallel development.

If then the alternative DVCS turns out to be very popular, we can shut
down the subversion repository.

That does not do away with the choice between Git/Hg though, unless
there are compelling reasons to keep on both.

N>

Other related posts: