A git mirror for Gnucash's Subversion Repository

[Geert Janssens]

On donderdag 17 februari 2011, John Ralls wrote:
> Several weeks ago we discussed here setting up a mirror on Github of our
> subversion repository. We set one up, but it then languished. I got
> motivated the other day to get going with it again and did some web
> research about how best to handle the workflow.  What I found [1][2]
> indicates that the following is the safest course:
> 
> Use git-svn to create and maintain a git repo from svn (I'll use my server
> for this for the moment; once we have everything ironed out we can get
> Derek to set up svn.gnucash.org to do it), periodically updating it with a
> cron job.
> 
> Clone the git repository to a public repository (this will be on Github in
> our case). This repo should be read only to everyone but the mirroring
> server.
> 
> Any developer who wants to use Git to work on Gnucash can clone the public
> repository -- but must never push to it. If he has svn commit privilege,
> he can also configure the git-svn information into his repo so that he can
> dcommit back into subversion. Those subversion changes will be eventually
> be reflected in the public git repo, and git-svn is smart enough to
> recognize the commit when it comes back around.
> 
> Developers can branch as they like in their own repositories, but when
> they're ready to bring a change back into svn trunk (or, soon, the 2.4
> stable branch in subversion) their changes have to be cleaned up and
> *rebased, not merged* into master. The reason for rebasing is that
> Subversion cannot handle multiply-parented changesets (or multiple
> children, for that matter; each branch or tag in subversion has a copy of
> all previous history up to the branch point). Rebasing recreates the
> changes in the branch on master. Yes, that breaks the git graph. On the
> other hand, it enables you to show a compressed series of changes evolving
> code into the finished product without revealing all of the false starts
> and mistakes you made as you were developing a new feature.
> 
> Developers without svn commit privs will have to send a pull request to
> someone who does. Github provides an easy mechanism for generating pull
> requests from one's own Github repo. Github also makes collaboration on
> feature branches easy -- they just have to be in your own Github Gnucash
> repo, not in the "official" one that mirrors subversion.
> 
> Does that make sense to everyone? Does anyone know of, or better yet, have
> experience with a another way?
> 
Looks like a very flexible setup to me and I'd love to experiment with this. 
Can you let us know when the git master clone is ready to play with ?

Geert