29 Nov
2009
29 Nov
'09
3:08 a.m.
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