[haiku-development] Re: Proposal: Moving away from Subversion
- From: David McPaul <dlmcpaul@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 23 Jun 2010 11:01:42 +1000
On 23 June 2010 06:31, Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
> Hi there,
>
> inspired by recent experience, I'd like to propose that we move away from
> using subversion as our version control system and use a distributed VCS
> instead.
>
> The most obvious advantages of such a move is that we'd be able to commit
> without being connected to the central repo and that branching/merging
> would be less of a pain.
I have always thought that committing code meant sending it to a
central repository. If it is not in trunk it is not committed.
> Mercurial and git have been discussed on this list already and I think
> those two are the most likely candidates.
Do we have working stable Haiku ports?
> I personally favour Mercurial because of its simplicity and higher cmdline
> compatibility with subversion.
> Additionally, the documentation of mercurial seems to be much more
> accessible than git's manpages and trac's mercurial plugin seems to be in a
> better shape than the ones for git.
>
> I have not yet checked the state of haiku's git port, but I've noticed that
> in order to get mercurial working on haiku, we'd need to fix quite some
> failing tests in Python's as well as Mercurial's testsuite.
A working Haiku port will be required.
> With any of git or mercurial, I'd suggest to keep the central repository
> approach, but additionally give every developer the chance to create a
> clone from the central repo in his home folder (which would then be part of
> the backup scheme).
> This way, everyone could experiment in his own repo or commit directly into
> the central repo.
>
> Anyway, I'd like to hear any input on whether or not we should drop
> subversion and, if so, which way we should go.
I am happy using Subversion. I work in my local repo and commit my
changes when I am ready.
I am not clashing with anyone codewise so merges are generally not an
issue. I know we are missing many of the visual svn tools that make
merging easier.
The only advantage I can think of for distributed version control is
the ability to have a local history of changes since each repo is it's
own branch.
You still have to deal with merging conflicts when committing to the real repo.
--
Cheers
David
Other related posts:
