[haiku-development] Re: Proposal: Moving away from Subversion
- From: Niels Reedijk <niels.reedijk@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 29 Jun 2010 09:02:20 +0200
Hi Alex,
On 28 June 2010 19:50, Alex von Gluck <kallisti5@xxxxxxxxxxx> wrote:
>
> From the discussions so far, here are the positives/negatives I am seeing
> weighted on each SCM:
>
> ------
> * Git
> ++ allows previously pulled branches to be easily discarded.
> ++ allows old revision data to be pruned from the local repository
> ++ git is mostly a compiled c executable, which runs flawlessly on Haiku
> ++ supports an unlimited number of parent revisions during a merge.
(...)
> * Hg
> ++ Easier learning curve, hg is more svn like
> ++ Revision numbers increment in a more easily understood fashion.
> ++ Source history is less-easily lost.
> -- Problems reported running under Haiku due to heavy Python requirement
> ++ Used by: (examples)
(...)
> There are lots of positives and negatives to each, definitely not an easy
> choice. However it looks as though more eyeballs are on git due to its
> larger user base. (which may be a positive as bugs are shallow... as Linus
> says ;) )
Debating every little detail about a tool really is the wrong way to
go. The question is not 'to which DVCS should we switch', it is which
decentralized workflow do we want to employ.
The excellent comparison article Alex quoted earlier gives a nice
message that there is a different philosophy between git and hg.
I identify two main modes of decentralized workflow: history-aware and
free-flow. The first one is closest to svn, where whenever something
is added to the 'log' (through a hg commit), it is fixed there. The
vanilla hg actually does not allow you to touch history in any way.
You cannot edit the order of commits, or even delete local named
branches within one repository. The free-flow is a-historical, where
commits flow like patches, they can be applied, removed, reordered. I
once said that git is a patch management tool with endless
possibilities.
Now I think the first workflow, the history-aware, is going to be the
workflow used by Haiku developers. The discourse on what the DVCS
should do seems to be mostly 'local commits' and 'easy merging'. And
if you look at how our project is structured, you see that there
really is not much complicated stuff going on. We do not have people
being bombarded by patches, we do not have to maintain many different
patch trees that need testing before they go into a final tree. In
fact, even with a DVCS, we would still mostly be working in a
star-like topology with one central repository and all the developers
as nodes connected to that repository.
Now git is very much capable of catering for that workflow, but hg is
tailored for it. Now I understand we live in a culture where product
differentiation can only be done by adding as much cruft as possible,
but I really don't see the sense in using an overly complicated tool
like git (where we would probably have to write our own manual and
conventions) to do the same thing that hg does as basic functionality.
Regards,
N>
Other related posts:
