On Wed, Mar 17, 2010 at 3:32 AM, Ed W <li...@wildgooses.com> wrote: > 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?
I never use svn merge because it sucks :-). I patch and commit because I get fewer errors that way. > > 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 http://github.com/jfkw/ledgersmb was contributed by one of our users. Maybe we should promote it (and his work)? I have some questions about github regarding permissions management and the like, but these may be git questions as well. > > 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. That's a good point. > > 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. I will talk with Jeff about the possibility of using his tree. I will also talk with the rest of the core team and get some more feedback. I personally think the time may be approaching to go this route. > > 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. Interesting. Best Wishes, Chris Travers ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
