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? Regards, John Ralls _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
