Proposals/feedback for a distributed version control system for cutecash?

[Derek Atkins]

Christian Stimming <stimming at tuhh.de> writes:

>> I think it's reasonable to think about migrating from SVN to git, but I
>> would want us going in with eyes wide open:
>> 
>> 1) WHY are we changing from SVN to a distributed VCS?
>
> My main reason: To make it easier for new contributors to contribute their 
> changes to a public place. With SVN they could send patches or attach them to 
> bugzilla, both which tend to be outdated quickly and get forgotten. With git, 
> they can either fork the whole repo (like on github.com) and push their 
> proposals there, or push to a personal branch in the main repo. In both cases 
> git takes care of most of the merging action, so it will be way easier to 
> merge their changes back in.

Are you proposing we use github as our main repo?  So we no longer use
code.gnucash.org to hold our code?  If not, then maybe you could help me
understand how we can securely allow random people to create git
branches on our server.

> Socially, this means we can get away a bit more from the development model of 
> "one true developer group" (those who have SVN write access) and rather move 
> into the direction of "some loose collection of contributors, some of which 
> contribute regularly, others only occasionally".

I'm still not sure how we do this in a secure way on code.gnucash.org.

> Additionally, the normal VCS operations are much faster in git. The
> speed improvement doesn't seem significant at first, but in the long
> run, having the common operations magnitudes faster also changes one's
> way of working, to the better.

I guess I've never noticed the slowness of SVN, but maybe that's because
I do all my work in SVK so all my operations are done off the local copy
of the repository.

>> 2) What features does the distributed VCS have that SVN does not (based
>>    on how we use SVN)?
>
> - Easier merging from the same branch to another, multiple times.

Okay, that's a good point.  SVN really only works for a single merge
back.  You can perform multiple merges into a branch (from trunk) but
can only really merge back once.

> - No extra write access to some central repo necessary for new contributors

Okay, I don't understand how this works.  How could a random person
create a public branch on code.gnucash.org?  This would seem like a
security nightmare!

> - Easier integration into sub-projects (cutecash) which would just merge the 
> main branch's changes regularly

This just sounds like a correllary of your first point, easier merging
from one branch to another, multiple times.

>> 3) Is there a viewer we could use (in lieu of trac)?
>
> I don't know. I've moved away from trac and instead look up everything
> in gitk locally (or maybe the git-gui file browser for annotation)
> because - I mentioned this already :-) - it is way faster. github.com
> has plenty of web viewing possibilities, see above. I'm not sure
> whether you can find everything there you were looking for, but I
> wouldn't miss anything if we continued without trac - but that's just
> my personal workflow.

I think trac is important for third parties looking to browse the code,
or to see what changes have been made to the mainline sources, or even
when was a particular tag made?  So I think a browser is important to
have.  It doesn't have to be trac per-se, but I think we need equivalent
functionality.

> Regards,
>
> Christian

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available