On Sat, Nov 28, 2009 at 9:08 PM, Colin Finck <[email protected]> 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.
_______________________________________________ Ros-dev mailing list [email protected] http://www.reactos.org/mailman/listinfo/ros-dev
