Re: ready to branch 1.3 off?

[Chris Travers <..hidden..>]

On Wed, Mar 17, 2010 at 3:32 AM, Ed W <..hidden..> 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