On Feb 16, 2011, at 11:57 PM, Christian Stimming wrote:
> Dear John and all,
>
> thanks a lot for setting this up! It is indeed interesting to see the latest
> SVN commits show up as cloned git commits rather soon by your cron job.
> https://github.com/Gnucash/gnucash/commits/master
>
> As discussed before, I'm very much interested to play around with this new
> possibilities and see how git can indeed make our workflow easier (e.g.
> forking on github etc). One fun feature of github are the comments on each
> commit, including comments on particular source code lines:
>
>
> https://github.com/Gnucash/gnucash/commit/91dc3f05bf16d0f352498289038191a5143daf13#configure.ac-P20
>
> Zitat von John Ralls <[email protected]>:
>> What I found [1][2] ...
>
> Errr, I didn't see the URLs to those references in your message...
>
>> 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.
>
> This is very much the workflow as described on
> http://stackoverflow.com/questions/1880405/can-different-git-svn-clones-of-the-same-svn-repository-expect-to-be-able-to-shar/3422422#3422422
> and the reference to
> http://blog.tfnico.com/2010/08/example-git-svn-mirror-workflow.html : As a
> developer with write access, I will continue to use git-svn locally, but with
> the shared public git repo in between and also running the command
>
> git update-ref refs/remotes/git-svn refs/remotes/origin/master
>
> each time after I've pulled from our shared git repo. Sounds doable.
>
>> 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.
>
> I expect a large benefit here because recently I've been doing a lot of patch
> committing, and it is cumbersome to figure out the correct -p argument which
> is different in each patch, and also setting up a suitable commit message. I
> expect if people send me a pull request I know I can already get their
> patches by the simple "git pull", not having to deal with patch formats or
> commit messages anymore. At least this part is surely an improvement for our
> (and particularly my) workflow.
Yes, it's the same workflow -- those URLs point to different places in the same
author's blog (and the stack overflow page has an answer from that same author).
Today I got the Loeliger book that Yawar cited. It does indeed have a different
approach, and if it works it will be more attractive because it allows the git
users to do git-ish things (almost) as much as they like. The penalty is that
only one repository is allowed to commit back to subversion.
1. Create a git-svn repository as usual, passing a --prefix=svn/ arg to git svn
clone. (Nicolaison doesn't use a prefix)
2. In a separate directory, create a bare git repo ("public") and git push -all
from the svn repo to the new bare one, mapping refs/remotes/svn/* in the
git-svn repo to refs/heads/svn/* in the new, bare, one. (Again, same for
Nicolaison but without the svn/ prefix.) Master is created as a tracking
branch of svn/trunk, and any active svn branches (think 2.4) will similarly
need tracking branches.
The public repository gets pushed to github and is periodically pulled back for
synchronizing with subversion. Here's where things get interesting. To sync
back into svn trunk (procedure would be the same for any subversion branch):
1. In the git svn repo, checkout master and pull from the public repo.
2. git checkout svn/trunk (This is in refs/remotes, so you get a detached head.)
3. git merge --no-ff master (Creates a merge commit rather than splicing the
commits. This loses some history in svn, but so it goes.)
4. git svn dcommit pushes the commit into subversion.
I've left out a bit of detail in the checkout and had to interpolate some in
for committing, so I'll have to test this out to make sure I have all of the
details right and that it actually works... but that's also true of
Nicolaison's method. Also, they're both silent on tags, and we need to
integrate our tags so that we know where releases occurred.
(Status: I have the perl version of svn2git written and the first run didn't
quite work; I think I mis-copied a command option. By the time I got that done,
it was dinner time, so I'll have another go tomorrow morning.)
Regards,
John Ralls
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
