[ros-dev] DVCS again [was: Trunk locked]
Gregor Schneider
grschneider at gmail.com
Sun Nov 29 13:46:48 CET 2009
I had similar ideas recently. Working with tortoisegit on Wine for one of my
patches felt weird first, but being able to commit changes locally and is
quite powerful. At first I wondered what it could be good for, but the
locked trunk showed me just that.
Keeping a history of patches which include commit messages and which even
might work separated from others is awesome.
Concerning the tortoiseGit GUI I have to agree that it's not as intuitive as
the SVN counterpart, but one always needs a certain time to get used to new
tools.
Big problem with those systems is the final checkin into the master branch.
The one person managing patch mails and applying all patches has the most
boring job ever. Furthermore this person has to have A LOT of time. No clue
which other concepts are supported by those two tools.
I remember seeing a GIT presentation by Torvalds at some Google event where
he introduced the Linux kernel "team" organisation.
Several maintainers who get patches for their area and himself being the
bigboss just copying their repos and not doing any patches at all. When a
checkout from a maintainer failed for him he just dropped it and took
anotherone.
Pretty cool tree like structure sounds possible here, but the concept of
maintainers or rather development areas/teams doesn't seem to work for
ReactOS. From the time when I started following ReactOS I proposed it
severeal times, but noone seems to be interested.
Gregor
2009/11/29 Colin Finck <mail at colinfinck.de>
> 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
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.reactos.org/pipermail/ros-dev/attachments/20091129/f5b0b629/attachment.htm
More information about the Ros-dev
mailing list