Re: ready to branch 1.3 off?

[John Locke <..hidden..>]

+1 to everything Ed said.

Using Jeff's repo is fine, and may be a good starting point. I have one,
too, though the branches probably aren't that well organized, and I do
need to add a post-update hook to update the master branch from svn
trunk (there's an svn/trunk branch that is up to date).

But I think there should be an official LSMB project on github, not
either Jeff's or mine... you can get a head start by cloning one of the
existing git repo's, and once the official one is in place, it doesn't
even really need the svn synchronization stuff.

FWIW, mine (and I'm guessing Jeff's too) already has a full SVN history,
every commit should be available. It pulls from SVN every 6 hours.

Mine's at:
git://git.freelock.com/git/ledgersmb.git

... browseable at http://git.freelock.com/?p=ledgersmb.git;a=summary

... Jeff's may well be easier to start from, especially to just clone
right on github.

Cheers,
John

-------- Original Message  --------
Subject: Re: [Ledger-smb-devel] ready to branch 1.3 off?
From: Chris Travers <..hidden..>
To: Development discussion for LedgerSMB
<..hidden..>
Date: Wed 17 Mar 2010 11:01:49 AM PDT
> 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
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>