[ros-dev] DVCS again [was: Trunk locked]

[Sir Gallantmon]

On Sat, Nov 28, 2009 at 9:08 PM, Colin Finck <mail at colinfinck.de> wrote:

> Zachary Gorden wrote:
> > This is common practice before a release and has been done for at least
> > the last year or so.
>
> You make it sound like locking the whole trunk and making the majority of
> developers unable to work properly is a state we want to keep.
> Of course, this has mostly been done due to having no alternatives when
> using Subversion and our urgent need to fix these blockers. But still, it's
> generally the worst possible action I can think of when it comes to
> collaborating on Open-Source projects...
>
> ... which raises the question about switching to a distributed version
> control system for me again.
>
> While Subversion has proven to be a viable solution for most of our needs,
> we still have to cope with its drawbacks from time to time.
> The major ones I can think of include:
>
>  * Build breakages in trunk prevent other developers from working.
>
>    Although some devs might have already get used to occasional build
>    breaks, this could become a bigger problem when, for example, two
>    developers constantly commit to a common component and update their
>    working copies afterwards.
>    They would immediately be forced to stop their work and wait for a fix,
>    when a build break occurs, even if it's lying in a completely different
>    component.
>
>    With Git or Mercurial, we could make wholly different workflows
>    possible here. A better one might be that each developer only works on
>    their own branches (which can be local and/or remote).
>    Optionally, two or more developers working on the same component could
>    also commit to a common branch, but still independent of the trunk or
>    master branch. If one needs stuff from a different branch, he can
>    easily merge single commits or fetch all changes from a branch.
>
>    Though SVN of course also provides branches, merging is far away from
>    being a transparent and trivial task there. I guess that the devs, who
>    often deal with our SVN branches, can confirm this.
>    Git or Mercurial solve this task way better.
>
>
>  * Not all commits in trunk are well-tested and easily make it unstable.
>
>    The recent locking of trunk again showed that it's still a place where
>    every trusted dev can, roughly speaking, commit whatever he wants.
>    It should be obvious that this leads to unexpected problems from time
>    to time.
>    Many people might also well remember the GL case, when the drastic
>    action of limiting one developer's SVN write access to branches was
>    done to prevent him from committing possibly problematic stuff to
>    trunk.
>
>    Using the branch workflow as described above would circumvent both
>    problems and even make trunk an unattractive place to work on.
>    If people have their own branches, where they can do everything they
>    want, to prepare a big change (e.g. that network locking rewrite),
>    nobody should ever need to work directly on trunk again.
>    We would just need to establish new rules or methods to get commits
>    from the branches into the trunk/master branch. Maybe a combination of
>    automatic and manual testing (depending on the situation) can help us
>    here.
>
> Such problems will turn out to be more severe with the raising number of
> developers.
>
> While this topic has already been partly discussed last year, the
> comfortable Windows support (= TortoiseSVN-like shell extensions) for both
> Git and Mercurial was still in very early stages of development at that
> time.
> This situation has improved much in the meantime. TortoiseGit and
> TortoiseHg should both provide most of the functions we need.
>
> The differences between Git&TortoiseGit and Mercurial&TortoiseHg lie more
> in the general concepts.
>
> As Git was designed with Unix principles in mind, it shares its
> one-tool-for-every-task approach. This way, it includes over 100 individual
> tools today to somehow solve every task and workflow. The official version
> also does not support Windows, but as msysgit and TortoiseGit exist today,
> this should be negligible. TortoiseGit is directly based on the TortoiseSVN
> source, so you should find it pretty easy to use.
>
> Mercurial was designed with more usability and interoperability in mind, so
> it's properly supported under all major platforms. Compared to Git, it only
> supports the most common commands.
> On the other hand, its TortoiseHg was designed the same way, meaning that
> it's a GTK application targeted to run under several platforms as well.
> Therefore the user interface is quite different to that of TortoiseSVN.
>
>
> After this rather long mail, I hope that we can eventually come to a
> conclusion about which distributed version control system to choose. Our
> existing Git mirror should be suitable for evaluating Git and I'm also
> doing a local import of the SVN repository into Mercurial right now (yes,
> it seems to work this time).
>
> By the way, we can still maintain a SVN backend for the trunk/master branch
> afterwards, so that people may still read the repository the same way
> as they have done before.
>
> Best regards,
>
> Colin
>
>
>
I have always found msysgit to be unusually slow in handling
checkouts/branching. Of course, given what MSYS really is, that really isn't
a surprise to me (MSYS is a fork of a really old version of Cygwin, 1.3.3 I
believe).

And while TortoiseGit is similar to TortoiseSVN, my experience with it has
led me to believe it is slower than its SVN counterpart.

TortoiseHG does work, but overall, I don't like using shell extensions, and
I haven't really used TortoiseHG recently since I got my new x64 Windows
desktop computer. It seems okay, but it looks sort of ugly on Vista and
higher thanks to the fact that GTK+ doesn't really render widgets on that
platform very well.

Mercurial itself, though, is very pleasant to use. I use it all the time for
my projects, and I feel that it would work well for ReactOS.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.reactos.org/pipermail/ros-dev/attachments/20091128/b9b686bf/attachment-0001.htm