On 14/03/2010 05:39, Adam Thompson wrote:
I don't follow this logic. SVN is perfectly capable of branching; merging and back-porting isn't as easy between branches as, say, git or bzr, but it looks like the codebases of 1.2, 1.3 and 2.0 will be sufficiently different that it would be highly unlikely patches could ever apply to multiple branches at the same time anyway.
My apologies if you are a git/bzr expert, but your comments make it sound like you have never used one of these newfangled DVCS systems?
Notice how the linux kernel is one of the big advocates of git and they maintain WILDLY diverged branches and yet git is so wickedly clever that you can very easily port patches forward/backward/sideways/whatever. It really is a phenominally clever bit of kit
Your comment also completely misses that I maintain a couple of small local changes to my installation - this is b*stardly difficult when upstream uses cvs/svn/similar, yet I have some other projects that I fork using git and it's just so unbelievably easy to go and hack locally and then still some *year* later you can pull in all the changes from upstream and it just takes some minutes of time usually to solve conflicts and integrate.
I also love being able to take some local modifications and merge those changes like a set of patches on top of multiple diverging tips of a development tree, ie exactly what you are arguing is impossible is sometimes very easy to maintain with git - you can develop some new feature as a set of independent patches and yet maintain that feature on top of versions 1.3 & 2.0 at the same time (obviously limited by the code itself, but the point is that these DVCS systems give you the tools to do this quite efficiently)
My vote would be to stick a github tree up. It's rapidly becoming the sourceforge.net equivalent.
Remember hosting on github does NOT prevent you from also maintaining your own private repo in svn, nor does it stop you hosting your own private git repo either on your own infrastructure (gitosis,etc) nor using your own laptop as the primary repo. The whole magic of git is that there is no "master repo", just a bunch of patches that you can push around as you like...
Github will get the project much more exposure and quite possibly more contributions. I forget which perl blog I was reading recently (probably from use.perl) but the were discussing how switching to github had impressively kickstarted code contributions.
Regards Ed W