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>