Merlijn van Deen <valhallasw@arctus.nl> wrote:
Another cause for this is the painful merging in most version control systems. I'm guessing you all know the pain of 'svn merge' - and there are a lot of projects still using SVN or even CVS.
As such, you need to impose the discipline to always apply changes to both branches. This is a reasonable thing for larger projects, but it is generally harder to implement it for smaller projects, as you're already lucky people are actually contributing.
What you say is all true, but I wonder if the additional work is really that much of a problem. Several people have said here that applying changes to both versions becomes second nature, and this is also my experience. While mercurial may be nicer, svnmerge.py isn't that bad. Projects have different needs and priorities. From my own experience with cdecimal I can positively say that the amount of work required to keep two branches [1] in sync is completely dwarfed by first figuring out what to write and then implementing it correctly. After doing all that, the actual synchronization work feels like a vacation. Another aspect, which may be again cdecimal-specific, is that keeping 2.5 compatibility is *at least* as bothersome as supporting 2.6/2.7 and 3.x. As an example for a pretty large project, it looks like Antoine is making good progress with Twisted: https://bitbucket.org/pitrou/t3k/wiki/Home I certainly can't say what's possible or best for other projects. I do think though that choosing the separate branches strategy will pay off eventually (at the very latest when Python-2.7 will reach the status that Python-1.5 currently has). Stefan Krah [1] I don't even use two branches but 2.c/3.c and 2.py/3.py file name patterns.