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

[John Ralls]

On Mar 30, 2010, at 8:14 AM, Derek Atkins wrote:

> Hi,
> 
> Christian Stimming <stimming at tuhh.de> writes:
> 
>> What would other devs around here choose as distributed VCS for a new
>> project, and why? Do you know of any hosting sites with that VCS that
>> offers continuous tracking of the original SVN branch?
> 
> I must admit that the only "distributed" VCS I've used is SVK, which is
> based around SVN.  It's... okay.  If I were to move to something else
> right now I think I'd move to git.
> 
> 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?
> 2) What features does the distributed VCS have that SVN does not (based
>   on how we use SVN)?
> 3) Is there a viewer we could use (in lieu of trac)?
> 
> I certainly think it would be very reasonable to supply our own
> read-only git repo.

There's not much point to a read-only git repo, as it's pretty easy to just use git-svn instead.

Well,  there's http://trac-hacks.org/wiki/GitPlugin which would let us stay with Trac.

I prefer git over svn because:
* The graphical interface (expressed as GitX on OSX) helps tailor commits into logical chunks even when I haven't been as incremental as I should be. It also provides a very nice way to see and browse the repository history and branch structure.
* It lets me easily set up a private branch and work on it with version control without messing up the public repository, and then carefully merge my successful changes back into master in a way that displays a logical progression of changes if the experiment works out. Via Github, that private branch can become public (as Christian is doing with Cutecash) without clogging up the master repo.
* git stash lets me easily set aside uncommitted changes in a branch and switch to another branch (typically master, to work on a bug report) and then come back to my work-in-progress.
* I can easily clone the private work onto my PPC machine and push the changes back. 
* Patch submission is much better. Instead of applying patches, submitters without push authority on the master repo (which means everyone on my projects) just create their own clone repos on github and develop away with complete VCS support. When they've got something ready, they send me a pull request. If they need help, I can make a branch and pull in their code and work on it with them; when it's all working, it gets merged into master and closed. Same thing if a patch (or even a complete rewrite) isn't a general enough solution, but contains an important kernel of code. For example,  I'm about ready to push a private branch of ige-mac-integration for Cocoa originally contributed by the Ardour developer; what he had worked for his Gtkmm app, but needed some major reworking to get it down to the glib/gtk+ level needed for general use.

Granted, it's possible to do the private branching and sharing between local machines with an svn tracking repo, but setting one up and maintaining it is a PITA, and it doesn't provide the ease of collaboration afforded by git.

I suppose, though, that looked at from a different angle, the ease of forking afforded by git/github or bzr/launchpad is that it makes it too easy for someone to create a competing fork. That cat's out of the bag already, though: Anyone can come along and do what Christian just did.

Consider also that almost the whole GNOME eco-system is now on Git, and many GNU and freedesktop projects have migrated as well. I offer that as testimonial, not as an alarm. After all, there are still projects in each that are still using cvs.


Regards,
John Ralls