git svn dcommit error ?

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

git svn dcommit error ?

Geert Janssens
I recently switched to using a git repo as described in the wiki. This has
worked fine until yesterday.

I'm currently trying to run a git svn dcommit to push some of my local commits
to svn. This results in an error however:

$ git svn dcommit                                                                                                                                          
Committing to svn+ssh://[hidden email]/repo/gnucash/trunk ...                                                                                                                  
        M       src/gnome-utils/assistant-utils.c                                                                                                                                        
Transaction is out of date: File '/gnucash/trunk/src/gnome-utils/assistant-
utils.c' is out of date at /usr/libexec/git-core/git-svn line 576


My tree is as follows:

... - A' - A - T - B

A: revision just before trunk
A': the revision even just before that
T: current trunk revision, both local and remote trunks
B: branch I'm trying to push to svn

I did run a git-update on trunk before trying to push. Trunk is up to date and
branch B is properly rebased on trunk, at least as far as I can see in gitk.

What confuses me is this: the error is about src/gnome-utils/assistant-utils.c
This file is last changed in revision A, and already pushed to svn. There are
no further changes to this file in either trunk or branch B. For some reason
git doesn't seem to agree on and tries to push the change anyway.

I suspect this is due to how revision A got committed:
A' and A were two revisions I created on two separate branches. When they were
ready, I first switched to the branch with A' and ran git svn dcommit. Next I
switched to trunk and ran git-update. This didn't change the remotes, because
the master repo at github hadn't synched yet. So at this point, local trunk
and the remote trunks were not pointing at the same commit. From there I
immediatly switched to the branch with A, rebased it to trunk and dcommitted
it as well. This worked fine on the svn side, but I wonder if this confused
things on the git side.

Basically, that leaves me with two questions:
1. how to recover from this situation ?
2. how can I/we prevent this from happening is the future ?

Geert
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: git svn dcommit error ?

John Ralls-2

On May 21, 2011, at 2:16 AM, Geert Janssens wrote:

> I recently switched to using a git repo as described in the wiki. This has
> worked fine until yesterday.
>
> I'm currently trying to run a git svn dcommit to push some of my local commits
> to svn. This results in an error however:
>
> $ git svn dcommit                                                                                                                                          
> Committing to svn+ssh://[hidden email]/repo/gnucash/trunk ...                                                                                                                  
>        M       src/gnome-utils/assistant-utils.c                                                                                                                                        
> Transaction is out of date: File '/gnucash/trunk/src/gnome-utils/assistant-
> utils.c' is out of date at /usr/libexec/git-core/git-svn line 576
>
>
> My tree is as follows:
>
> ... - A' - A - T - B
>
> A: revision just before trunk
> A': the revision even just before that
> T: current trunk revision, both local and remote trunks
> B: branch I'm trying to push to svn
>
> I did run a git-update on trunk before trying to push. Trunk is up to date and
> branch B is properly rebased on trunk, at least as far as I can see in gitk.
>
> What confuses me is this: the error is about src/gnome-utils/assistant-utils.c
> This file is last changed in revision A, and already pushed to svn. There are
> no further changes to this file in either trunk or branch B. For some reason
> git doesn't seem to agree on and tries to push the change anyway.
>
> I suspect this is due to how revision A got committed:
> A' and A were two revisions I created on two separate branches. When they were
> ready, I first switched to the branch with A' and ran git svn dcommit. Next I
> switched to trunk and ran git-update. This didn't change the remotes, because
> the master repo at github hadn't synched yet. So at this point, local trunk
> and the remote trunks were not pointing at the same commit. From there I
> immediatly switched to the branch with A, rebased it to trunk and dcommitted
> it as well. This worked fine on the svn side, but I wonder if this confused
> things on the git side.
>
> Basically, that leaves me with two questions:
> 1. how to recover from this situation ?
> 2. how can I/we prevent this from happening is the future ?


Take a look at `git log --full-history A'..B src/gnome-utils/assistant-utils.c` (filling in the actual commit short hashes for A' and B, of course). It should show what git thinks are the differences.

Regards,
John Ralls




_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: git svn dcommit error ?

Geert Janssens
On zaterdag 21 mei 2011, John Ralls wrote:
> Take a look at `git log --full-history A'..B
> src/gnome-utils/assistant-utils.c` (filling in the actual commit short
> hashes for A' and B, of course). It should show what git thinks are the
> differences.
>
$ git log --full-history c46431964..gtk2.18 src/gnome-utils/assistant-utils.c
commit b0d4b0c75fcb7f91ad60e68a1939c844e8333602
Author: Geert Janssens <[hidden email]>
Date:   Fri May 20 16:31:42 2011 +0000

    Replace obsolete gnome include with gtk include
   
    git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@20665
57a11ea4-9604-0410-9ed3-97b8803252fd

This commit is commit A in my diagram above and is pushed to svn as revision
20665.

Geert

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: git svn dcommit error ?

John Ralls-2

On May 21, 2011, at 8:29 AM, Geert Janssens wrote:

> On zaterdag 21 mei 2011, John Ralls wrote:
>> Take a look at `git log --full-history A'..B
>> src/gnome-utils/assistant-utils.c` (filling in the actual commit short
>> hashes for A' and B, of course). It should show what git thinks are the
>> differences.
>>
> $ git log --full-history c46431964..gtk2.18 src/gnome-utils/assistant-utils.c
> commit b0d4b0c75fcb7f91ad60e68a1939c844e8333602
> Author: Geert Janssens <[hidden email]>
> Date:   Fri May 20 16:31:42 2011 +0000
>
>    Replace obsolete gnome include with gtk include
>
>    git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@20665
> 57a11ea4-9604-0410-9ed3-97b8803252fd
>
> This commit is commit A in my diagram above and is pushed to svn as revision
> 20665.

OK. A bit of googling takes me to [1], which is part of what taught me how to set this up.

There, I'm reminded that the problem is likely that your git reference to SVN is outdated because of the round-trip from your repo to svn to github (via my server). Running git-update should patch up the references so that your dcommit will work.

Regards,
John Ralls


[1] http://blog.tfnico.com/2010/10/gitsvn-5-centralized-git-svn-mirror.html
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: git svn dcommit error ?

Geert Janssens
On zaterdag 21 mei 2011, John Ralls wrote:

> On May 21, 2011, at 8:29 AM, Geert Janssens wrote:
> > On zaterdag 21 mei 2011, John Ralls wrote:
> >> Take a look at `git log --full-history A'..B
> >> src/gnome-utils/assistant-utils.c` (filling in the actual commit short
> >> hashes for A' and B, of course). It should show what git thinks are the
> >> differences.
> >
> > $ git log --full-history c46431964..gtk2.18
> > src/gnome-utils/assistant-utils.c commit
> > b0d4b0c75fcb7f91ad60e68a1939c844e8333602
> > Author: Geert Janssens <[hidden email]>
> > Date:   Fri May 20 16:31:42 2011 +0000
> >
> >    Replace obsolete gnome include with gtk include
> >    
> >    git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@20665
> >
> > 57a11ea4-9604-0410-9ed3-97b8803252fd
> >
> > This commit is commit A in my diagram above and is pushed to svn as
> > revision 20665.
>
> OK. A bit of googling takes me to [1], which is part of what taught me how
> to set this up.
>
> There, I'm reminded that the problem is likely that your git reference to
> SVN is outdated because of the round-trip from your repo to svn to github
> (via my server). Running git-update should patch up the references so that
> your dcommit will work.
>
I wish that were so:

$ git-update
warning: refname 'trunk' is ambiguous.
Current branch trunk is up to date.

$ git checkout gtk2.18
Switched to branch 'gtk2.18'

$ git svn dcommit
Committing to svn+ssh://[hidden email]/repo/gnucash/trunk ...
        M       src/gnome-utils/assistant-utils.c
Transaction is out of date: File '/gnucash/trunk/src/gnome-utils/assistant-
utils.c' is out of date at /usr/libexec/git-core/git-svn line 576

I'm afraid I don't understand this well enough to know what to do next. I read
the link you referred to, but other than what you proposed there seems nothing
in there that could help.

Geert
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: git svn dcommit error ?

John Ralls-2

On May 21, 2011, at 10:14 AM, Geert Janssens wrote:

> On zaterdag 21 mei 2011, John Ralls wrote:
>> On May 21, 2011, at 8:29 AM, Geert Janssens wrote:
>>> On zaterdag 21 mei 2011, John Ralls wrote:
>>>> Take a look at `git log --full-history A'..B
>>>> src/gnome-utils/assistant-utils.c` (filling in the actual commit short
>>>> hashes for A' and B, of course). It should show what git thinks are the
>>>> differences.
>>>
>>> $ git log --full-history c46431964..gtk2.18
>>> src/gnome-utils/assistant-utils.c commit
>>> b0d4b0c75fcb7f91ad60e68a1939c844e8333602
>>> Author: Geert Janssens <[hidden email]>
>>> Date:   Fri May 20 16:31:42 2011 +0000
>>>
>>>   Replace obsolete gnome include with gtk include
>>>
>>>   git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@20665
>>>
>>> 57a11ea4-9604-0410-9ed3-97b8803252fd
>>>
>>> This commit is commit A in my diagram above and is pushed to svn as
>>> revision 20665.
>>
>> OK. A bit of googling takes me to [1], which is part of what taught me how
>> to set this up.
>>
>> There, I'm reminded that the problem is likely that your git reference to
>> SVN is outdated because of the round-trip from your repo to svn to github
>> (via my server). Running git-update should patch up the references so that
>> your dcommit will work.
>>
> I wish that were so:
>
> $ git-update
> warning: refname 'trunk' is ambiguous.
> Current branch trunk is up to date.
>
> $ git checkout gtk2.18
> Switched to branch 'gtk2.18'
>
> $ git svn dcommit
> Committing to svn+ssh://[hidden email]/repo/gnucash/trunk ...
>        M       src/gnome-utils/assistant-utils.c
> Transaction is out of date: File '/gnucash/trunk/src/gnome-utils/assistant-
> utils.c' is out of date at /usr/libexec/git-core/git-svn line 576
>
> I'm afraid I don't understand this well enough to know what to do next. I read
> the link you referred to, but other than what you proposed there seems nothing
> in there that could help.

Ah, that's not what you said you were doing.
There is no gtk2.18 branch in the svn repo, so you can't dcommit that branch until you create one. I think that
git svn branch -m "Feature Branch for updating Gnucash UI to gtk2.18"
should do it, but you'll need to pay attention to the git svn output make sure that it does the right thing; you may need to dcommit the changes after creating the branch, and you may need to fiddle with the config of your local branch so that it tracks the new svn branch.

This will not, of course, add your changes to trunk, and it will mean that you will have to work in this feature branch until you're finished with it: With Subversion, you get only one merge from a feature branch back to trunk.

This is probably not what you want to do. What you want to do is what you said that you'd done in your original message:
Rebase your gtk2.18 branch onto trunk and dcommit trunk and dcommit trunk to subversion.
git checkout trunk
git rebase gtk2.18
git svn dcommit
(wait until after the next update; if you hurry, you can get in before the next one which starts at 1900Z)
git-update
git checkout gtk2.18
git merge trunk

And you're ready to go back to work.


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: git svn dcommit error ?

Geert Janssens
On zaterdag 21 mei 2011, John Ralls wrote:

> On May 21, 2011, at 10:14 AM, Geert Janssens wrote:
> > On zaterdag 21 mei 2011, John Ralls wrote:
> >> On May 21, 2011, at 8:29 AM, Geert Janssens wrote:
> >>> On zaterdag 21 mei 2011, John Ralls wrote:
> >>>> Take a look at `git log --full-history A'..B
> >>>> src/gnome-utils/assistant-utils.c` (filling in the actual commit short
> >>>> hashes for A' and B, of course). It should show what git thinks are
> >>>> the differences.
> >>>
> >>> $ git log --full-history c46431964..gtk2.18
> >>> src/gnome-utils/assistant-utils.c commit
> >>> b0d4b0c75fcb7f91ad60e68a1939c844e8333602
> >>> Author: Geert Janssens <[hidden email]>
> >>> Date:   Fri May 20 16:31:42 2011 +0000
> >>>
> >>>   Replace obsolete gnome include with gtk include
> >>>  
> >>>   git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@20665
> >>>
> >>> 57a11ea4-9604-0410-9ed3-97b8803252fd
> >>>
> >>> This commit is commit A in my diagram above and is pushed to svn as
> >>> revision 20665.
> >>
> >> OK. A bit of googling takes me to [1], which is part of what taught me
> >> how to set this up.
> >>
> >> There, I'm reminded that the problem is likely that your git reference
> >> to SVN is outdated because of the round-trip from your repo to svn to
> >> github (via my server). Running git-update should patch up the
> >> references so that your dcommit will work.
> >
> > I wish that were so:
> >
> > $ git-update
> > warning: refname 'trunk' is ambiguous.
> > Current branch trunk is up to date.
> >
> > $ git checkout gtk2.18
> > Switched to branch 'gtk2.18'
> >
> > $ git svn dcommit
> > Committing to svn+ssh://[hidden email]/repo/gnucash/trunk ...
> >
> >        M       src/gnome-utils/assistant-utils.c
> >
> > Transaction is out of date: File
> > '/gnucash/trunk/src/gnome-utils/assistant- utils.c' is out of date at
> > /usr/libexec/git-core/git-svn line 576
> >
> > I'm afraid I don't understand this well enough to know what to do next. I
> > read the link you referred to, but other than what you proposed there
> > seems nothing in there that could help.
>
> Ah, that's not what you said you were doing.
> There is no gtk2.18 branch in the svn repo, so you can't dcommit that
> branch until you create one.
That doesn't seem correct. I have done that without any problems for all my
previous dcommits, which have been from a gtk2.18 branch, a bugfix branch,...
All these branches are rebased on trunk before dcommitting, but I'm definitly
running the dcommit from the working branches, not trunk.

> I think that git svn branch -m "Feature
> Branch for updating Gnucash UI to gtk2.18" should do it, but you'll need
> to pay attention to the git svn output make sure that it does the right
> thing; you may need to dcommit the changes after creating the branch, and
> you may need to fiddle with the config of your local branch so that it
> tracks the new svn branch.
>
> This will not, of course, add your changes to trunk, and it will mean that
> you will have to work in this feature branch until you're finished with
> it: With Subversion, you get only one merge from a feature branch back to
> trunk.
>
> This is probably not what you want to do.
Indeed, I don't want to create additional branches in svn.

> What you want to do is what you
> said that you'd done in your original message: Rebase your gtk2.18 branch
> onto trunk and dcommit trunk and dcommit trunk to subversion.
> git checkout trunk
> git rebase gtk2.18
> git svn dcommit

What I have done so far which has always worked until now:
Work on a git local branch (like gtk2.18), these branches are all branched off
of trunk.
When I'm ready to push to svn:
git checkout trunk
git-update
git rebase trunk gtk2.18
git svn dcommit

Until this last attempt this has always worked. I never needed my working
branch to exist in svn, the revisions got always pushed to svn trunk.

But now you seem to suggest that is backwards, and I should rebase trunk on
gtk2.18 instead of the other way around ?

Anyway, I tried these steps, but the error is still the same, so there must be
something else not right in my local repo.

> (wait until after the next update; if you hurry, you can get in before the
> next one which starts at 1900Z) git-update
> git checkout gtk2.18
> git merge trunk
>
> And you're ready to go back to work.

Just for the record, my follow-up steps always were
git-update
git rebase trunk gtk2.18

So far I have always avoided merging, because I thought that might lead to
trouble with the svn interactions.

Geert
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: git svn dcommit error ?

Geert Janssens
On zaterdag 21 mei 2011, Geert Janssens wrote:

> On zaterdag 21 mei 2011, John Ralls wrote:
> > On May 21, 2011, at 10:14 AM, Geert Janssens wrote:
> > > On zaterdag 21 mei 2011, John Ralls wrote:
> > >> On May 21, 2011, at 8:29 AM, Geert Janssens wrote:
> > >>> On zaterdag 21 mei 2011, John Ralls wrote:
> > >>>> Take a look at `git log --full-history A'..B
> > >>>> src/gnome-utils/assistant-utils.c` (filling in the actual commit
> > >>>> short hashes for A' and B, of course). It should show what git
> > >>>> thinks are the differences.
> > >>>
> > >>> $ git log --full-history c46431964..gtk2.18
> > >>> src/gnome-utils/assistant-utils.c commit
> > >>> b0d4b0c75fcb7f91ad60e68a1939c844e8333602
> > >>> Author: Geert Janssens <[hidden email]>
> > >>> Date:   Fri May 20 16:31:42 2011 +0000
> > >>>
> > >>>   Replace obsolete gnome include with gtk include
> > >>>  
> > >>>   git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@20665
> > >>>
> > >>> 57a11ea4-9604-0410-9ed3-97b8803252fd
> > >>>
> > >>> This commit is commit A in my diagram above and is pushed to svn as
> > >>> revision 20665.
> > >>
> > >> OK. A bit of googling takes me to [1], which is part of what taught me
> > >> how to set this up.
> > >>
> > >> There, I'm reminded that the problem is likely that your git reference
> > >> to SVN is outdated because of the round-trip from your repo to svn to
> > >> github (via my server). Running git-update should patch up the
> > >> references so that your dcommit will work.
> > >
> > > I wish that were so:
> > >
> > > $ git-update
> > > warning: refname 'trunk' is ambiguous.
> > > Current branch trunk is up to date.
> > >
> > > $ git checkout gtk2.18
> > > Switched to branch 'gtk2.18'
> > >
> > > $ git svn dcommit
> > > Committing to svn+ssh://[hidden email]/repo/gnucash/trunk
> > > ...
> > >
> > >        M       src/gnome-utils/assistant-utils.c
> > >
> > > Transaction is out of date: File
> > > '/gnucash/trunk/src/gnome-utils/assistant- utils.c' is out of date at
> > > /usr/libexec/git-core/git-svn line 576
> > >
> > > I'm afraid I don't understand this well enough to know what to do next.
> > > I read the link you referred to, but other than what you proposed
> > > there seems nothing in there that could help.
> >
> > Ah, that's not what you said you were doing.
> > There is no gtk2.18 branch in the svn repo, so you can't dcommit that
> > branch until you create one.
>
> That doesn't seem correct. I have done that without any problems for all my
> previous dcommits, which have been from a gtk2.18 branch, a bugfix
> branch,... All these branches are rebased on trunk before dcommitting, but
> I'm definitly running the dcommit from the working branches, not trunk.
>
> > I think that git svn branch -m "Feature
> > Branch for updating Gnucash UI to gtk2.18" should do it, but you'll need
> > to pay attention to the git svn output make sure that it does the right
> > thing; you may need to dcommit the changes after creating the branch, and
> > you may need to fiddle with the config of your local branch so that it
> > tracks the new svn branch.
> >
> > This will not, of course, add your changes to trunk, and it will mean
> > that you will have to work in this feature branch until you're finished
> > with it: With Subversion, you get only one merge from a feature branch
> > back to trunk.
> >
> > This is probably not what you want to do.
>
> Indeed, I don't want to create additional branches in svn.
>
> > What you want to do is what you
> > said that you'd done in your original message: Rebase your gtk2.18 branch
> > onto trunk and dcommit trunk and dcommit trunk to subversion.
> > git checkout trunk
> > git rebase gtk2.18
> > git svn dcommit
>
> What I have done so far which has always worked until now:
> Work on a git local branch (like gtk2.18), these branches are all branched
> off of trunk.
> When I'm ready to push to svn:
> git checkout trunk
> git-update
> git rebase trunk gtk2.18
> git svn dcommit
>
> Until this last attempt this has always worked. I never needed my working
> branch to exist in svn, the revisions got always pushed to svn trunk.
>
> But now you seem to suggest that is backwards, and I should rebase trunk on
> gtk2.18 instead of the other way around ?
>
> Anyway, I tried these steps, but the error is still the same, so there must
> be something else not right in my local repo.
>
> > (wait until after the next update; if you hurry, you can get in before
> > the next one which starts at 1900Z) git-update
> > git checkout gtk2.18
> > git merge trunk
> >
> > And you're ready to go back to work.
>
> Just for the record, my follow-up steps always were
> git-update
> git rebase trunk gtk2.18
>
> So far I have always avoided merging, because I thought that might lead to
> trouble with the svn interactions.
>
> Geert
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Ah, I have found the answer [1]

I think my workflow is ok in general, but not very resilient due to the
updates.

From the link, I gather that git svn's "internal working directory" (or
whatever git's representation of its svn interface should be called) was in a
mixed checkout state.

I probably created this by dcommitting from two separate git working branches
without first waiting for a repo sync, then git-updating and then rebasing my
working branches to the new trunk.

Anyway the solution is the remove the .git/svn directory to reset git-svn's
metadata. After that, dcommit worked again.

I can see also now that this probably can be avoided altogether by using your
workflow, namely rebasing trunk on the working branch you want to dcommit
instead of the other way around. That ensures all dcommits happen from the
same branch (trunk).

I'll note that this was not clear from our git wiki page. I have added an
example workflow so other new users of our git setup don't have to make the
same mistakes. Can you proofread my additions to make sure I didn't write too
much nonsense ?

Pfew, mixing rcs's can bring up some subtle complications.

Geert

[1] http://stackoverflow.com/questions/2922059/how-to-recover-from-an-
unwanted-rename-using-git-svn-transaction-is-out-of-date
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: git-svn and local feature branch (git svn dcommit error ?)

Christian Stimming-4
Am Samstag, 21. Mai 2011 schrieb Geert Janssens:

> I probably created this by dcommitting from two separate git working
> branches without first waiting for a repo sync, then git-updating and then
> rebasing my working branches to the new trunk.
>
> Anyway the solution is the remove the .git/svn directory to reset git-svn's
> metadata. After that, dcommit worked again.
>
> I can see also now that this probably can be avoided altogether by using
> your workflow, namely rebasing trunk on the working branch you want to
> dcommit instead of the other way around. That ensures all dcommits happen
> from the same branch (trunk).

Right, that's what I would have suggested as well (probably). I'd say that
since all commits to SVN inherently need to be rebased on SVN-trunk, the
developer should probably rebase or cherry-pick them to his local trunk
tracking branch, then always svn-dcommit from that same trunk tracking branch.

> I'll note that this was not clear from our git wiki page. I have added an
> example workflow so other new users of our git setup don't have to make the
> same mistakes. Can you proofread my additions to make sure I didn't write
> too much nonsense ?

Why do you run the rebase the way you do? You rebase your trunk on your local
feature branch, which means you will change your trunk branch:

I would have expected that the other way round first: Your feature branch need
to be rebased on trunk because for SVN, any of your changes must be rebased on
SVN's trunk anyway. Then, you can "rebase" (or rather: fast-forward) your
local trunk on feature which means your local trunk is based on SVN-trunk plus
all commits from your feature branch. Then, you can dcommit.

I wouldn't expect a "git merge" anywhere in this workflow, again because SVN
forces us to rebase for anything that is dcommitted. The only exception would
be to keep around a feature branch that is based on some older trunk commit
and it contains stuff that is not (yet) in SVN trunk. However, in that case I
would cherry-pick specific commits from the feature branch into trunk, dcommit
those to SVN, and only then run "git checkout feature; git merge trunk". But
you won't need that if your feature branch was dcommitted to SVN in full
anyway.

Regards,

Christian
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: git-svn and local feature branch (git svn dcommit error ?)

John Ralls-2

On May 21, 2011, at 2:52 PM, Christian Stimming wrote:

> Am Samstag, 21. Mai 2011 schrieb Geert Janssens:
>> I probably created this by dcommitting from two separate git working
>> branches without first waiting for a repo sync, then git-updating and then
>> rebasing my working branches to the new trunk.
>>
>> Anyway the solution is the remove the .git/svn directory to reset git-svn's
>> metadata. After that, dcommit worked again.
>>
>> I can see also now that this probably can be avoided altogether by using
>> your workflow, namely rebasing trunk on the working branch you want to
>> dcommit instead of the other way around. That ensures all dcommits happen
>> from the same branch (trunk).
>
> Right, that's what I would have suggested as well (probably). I'd say that
> since all commits to SVN inherently need to be rebased on SVN-trunk, the
> developer should probably rebase or cherry-pick them to his local trunk
> tracking branch, then always svn-dcommit from that same trunk tracking branch.
>
>> I'll note that this was not clear from our git wiki page. I have added an
>> example workflow so other new users of our git setup don't have to make the
>> same mistakes. Can you proofread my additions to make sure I didn't write
>> too much nonsense ?
>
> Why do you run the rebase the way you do? You rebase your trunk on your local
> feature branch, which means you will change your trunk branch:
>
> I would have expected that the other way round first: Your feature branch need
> to be rebased on trunk because for SVN, any of your changes must be rebased on
> SVN's trunk anyway. Then, you can "rebase" (or rather: fast-forward) your
> local trunk on feature which means your local trunk is based on SVN-trunk plus
> all commits from your feature branch. Then, you can dcommit.
>
> I wouldn't expect a "git merge" anywhere in this workflow, again because SVN
> forces us to rebase for anything that is dcommitted. The only exception would
> be to keep around a feature branch that is based on some older trunk commit
> and it contains stuff that is not (yet) in SVN trunk. However, in that case I
> would cherry-pick specific commits from the feature branch into trunk, dcommit
> those to SVN, and only then run "git checkout feature; git merge trunk". But
> you won't need that if your feature branch was dcommitted to SVN in full
> anyway.

The procedure in the Wiki page is what I think is correct (and what I've done).

It's perfectly normal in git to get part of a complicated feature done and copy that bit to the main branch (trunk for us, but "master" is the usual name in git repos) and then to keep working on the feature branch. In that case one should periodically merge the main branch into the feature branch so that the feature branch stays reasonably close to the main branch.  That's not allowed in the released version of subversion because of the way it handles merges (and has no concept of rebasing or cherry-picking). The development branch of subversion is supposed to handle this better... I haven't tried it though.

Regards,
John Ralls

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: git-svn and local feature branch (git svn dcommit error ?)

Christian Stimming-4
Am Sonntag, 22. Mai 2011 schrieb John Ralls:
> The procedure in the Wiki page is what I think is correct (and what I've
> done).
>
> It's perfectly normal in git to get part of a complicated feature done and
> copy that bit to the main branch (trunk for us, but "master" is the usual
> name in git repos) and then to keep working on the feature branch. In that
> case one should periodically merge the main branch into the feature branch

Yes, absolutely, for the normal git workflow.

However, here we are talking about the git-svn branch from which we want to
dcommit to SVN. The IMHO unexpected part here is this:

> git checkout trunk
> git rebase feature
> git svn dcommit

I.e. why is the "trunk" rebased on top of the "feature" branch, then being d-
committed? Either all of the feature branch should go into SVN, in which case
I would rebase "feature" on top of "trunk" (i.e. the other way round compared
to the above steps). Or the "feature" commits should not (yet) be committed,
in which case I would do

> git checkout feature
> git merge trunk

and then occasionally cherry-pick some of "feature"'s commits into trunk and
d-commit from there. In the end, I would again rebase "feature" on top of
"trunk" and this way d-commit all the commits that haven't been cherry-picked
to trunk before.

I agree this "git merge trunk" is written in the end of this new section, and
that's what I have expected. But the "git rebase feature" still looks
unexpected to me.

Regards,

Christian
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: git-svn and local feature branch (git svn dcommit error ?)

John Ralls-2

On May 22, 2011, at 12:54 PM, Christian Stimming wrote:

> Am Sonntag, 22. Mai 2011 schrieb John Ralls:
>> The procedure in the Wiki page is what I think is correct (and what I've
>> done).
>>
>> It's perfectly normal in git to get part of a complicated feature done and
>> copy that bit to the main branch (trunk for us, but "master" is the usual
>> name in git repos) and then to keep working on the feature branch. In that
>> case one should periodically merge the main branch into the feature branch
>
> Yes, absolutely, for the normal git workflow.
>
> However, here we are talking about the git-svn branch from which we want to
> dcommit to SVN. The IMHO unexpected part here is this:
>
>> git checkout trunk
>> git rebase feature
>> git svn dcommit
>
> I.e. why is the "trunk" rebased on top of the "feature" branch, then being d-
> committed? Either all of the feature branch should go into SVN, in which case
> I would rebase "feature" on top of "trunk" (i.e. the other way round compared
> to the above steps). Or the "feature" commits should not (yet) be committed,
> in which case I would do
>
>> git checkout feature
>> git merge trunk
>
> and then occasionally cherry-pick some of "feature"'s commits into trunk and
> d-commit from there. In the end, I would again rebase "feature" on top of
> "trunk" and this way d-commit all the commits that haven't been cherry-picked
> to trunk before.
>
> I agree this "git merge trunk" is written in the end of this new section, and
> that's what I have expected. But the "git rebase feature" still looks
> unexpected to me.

Sorry, you're right. I got the direction of rebase backwards. So it should be

git checkout feature
git rebase trunk
(Or just `git rebase trunk feature` which does both steps at once)
git svn dcommit

You're probably right about cherry-picking, too. (You can cherry-pick all of the changes at once with `git cherry-pick ..trunk` when checked out in feature.) Rebasing might have contributed to Geert's remote refs getting messed up.

Starting with
     B - D - E Feature
  /
A  - C - F Trunk

Rebasing does this:

                 B' - D' - E'  
               /
A - C- F  

If you dcommit with E' checked out (which is where you'll be after the rebase), Github:Gnucash/gnucash will see

A - C - F - B" - D" - E"

When you run git-update you'll have

                  B' - D' - E'
               /
A - C - F - B" - D" - E"

And a merge will adjust your references to

                  B'   -   D'   -   E'
               /                     /
A - C - F - B" - D" - E"

On the other hand, cherry-picking the whole thing will produce
    B - D - E
  /
A  - C - F - B' - D' - E'

Which after dcommitting, git-updating, and merging will look like:

    B       -        D      -      E
  /                                  /
A  - C - F - B" - D" - E"

Which is a better reflection of history and has less chance of references getting screwed up. On the other hand, you have to make sure that your checked out on trunk at E' when you dcommit (or say `git svn dcommit trunk`) or you'll wind up dcommitting your feature branch to subversion, which will make a bit of a mess.

Regards,
John Ralls


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: git-svn and local feature branch (git svn dcommit error ?)

Geert Janssens
On maandag 23 mei 2011, John Ralls wrote:

> On May 22, 2011, at 12:54 PM, Christian Stimming wrote:
> > Am Sonntag, 22. Mai 2011 schrieb John Ralls:
> >> The procedure in the Wiki page is what I think is correct (and what I've
> >> done).
> >>
> >> It's perfectly normal in git to get part of a complicated feature done
> >> and copy that bit to the main branch (trunk for us, but "master" is the
> >> usual name in git repos) and then to keep working on the feature
> >> branch. In that case one should periodically merge the main branch into
> >> the feature branch
> >
> > Yes, absolutely, for the normal git workflow.
> >
> > However, here we are talking about the git-svn branch from which we want
> > to
> >
> > dcommit to SVN. The IMHO unexpected part here is this:
> >> git checkout trunk
> >> git rebase feature
> >> git svn dcommit
> >
> > I.e. why is the "trunk" rebased on top of the "feature" branch, then
> > being d- committed? Either all of the feature branch should go into SVN,
> > in which case I would rebase "feature" on top of "trunk" (i.e. the other
> > way round compared to the above steps). Or the "feature" commits should
> > not (yet) be committed, in which case I would do
> >
> >> git checkout feature
> >> git merge trunk
> >
> > and then occasionally cherry-pick some of "feature"'s commits into trunk
> > and d-commit from there. In the end, I would again rebase "feature" on
> > top of "trunk" and this way d-commit all the commits that haven't been
> > cherry-picked to trunk before.
> >
> > I agree this "git merge trunk" is written in the end of this new section,
> > and that's what I have expected. But the "git rebase feature" still
> > looks unexpected to me.
>
> Sorry, you're right. I got the direction of rebase backwards. So it should
> be
>
> git checkout feature
> git rebase trunk
> (Or just `git rebase trunk feature` which does both steps at once)
> git svn dcommit
>
Right, that is what I have been doing all the time and why I was surprised
about your setup. But considering my limited experience with git, I was
willing to follow your workflow.

> You're probably right about cherry-picking, too. (You can cherry-pick all
> of the changes at once with `git cherry-pick ..trunk` when checked out in
> feature.) Rebasing might have contributed to Geert's remote refs getting
> messed up.
>
Yes, I think so too. And particularly rebasing while the two remotes involved
(svn and John's github master repo) are not in sync.
As said before, I wanted to dcommit two separate feature branches right one
after the other. They were both rebased to the actual remote trunk just before
I started the process of dcomitting.

    B - D - E      Feature 1
  /
A                  Trunk (both local and remote)
  \
    G              Feature 2


The first dcommit worked fine:

    B' - D' - E'      Feature 1, Trunk local, Trunk svn
  /
A                  Trunk github
  \
    G              Feature 2

At that point I got unsure. Just to be sure I now ran git-update, which
resulted in this:

    B' - D' - E'      Feature 1, Trunk svn
  /
A                  Trunk github, Trunk local
  \
    G              Feature 2

And I think that was a mistake. Github hadn't synched yet with subversion, so
it rebased trunk back to the github's trunk, while svn's trunk was pointing to
my feature 1. Perhaps internally, this also messed up git-svn's state, I can't
tell.

Assuming I should always commit to trunk, and my Feature 2 branch was again
based on trunk due to the git-update action, I continued to dcommit Feature 2.
This worked fine, although I don't know exactly what the new state became.

After that I didn't do anything anymore until after the next github svn sync.
And from there on, I got the issues I reported.

I now think I would have avoided these problems if I didn't run the git-update
command in between the two dcommits. Instead I should have rebased feature 2
on top of feature 1. Wether I'd have done that before or after the first
dcommit is probably not really important.

> Starting with
>      B - D - E Feature
>   /
> A  - C - F Trunk
>
> Rebasing does this:
>
>                  B' - D' - E'
>                /
> A - C- F
>
> If you dcommit with E' checked out (which is where you'll be after the
> rebase), Github:Gnucash/gnucash will see
>
> A - C - F - B" - D" - E"
>
...that is, after the next time github and svn are synched together.

> When you run git-update you'll have
>
>                   B' - D' - E'
>                /
> A - C - F - B" - D" - E"
>
Again, only if you wait until after the next sync. If you don't wait before
running git-update, your local trunk will be dissociated from git-svn's trunk
and be reset to F.

> And a merge will adjust your references to
>
>                   B'   -   D'   -   E'
>                /                     /
> A - C - F - B" - D" - E"
>
> On the other hand, cherry-picking the whole thing will produce
>     B - D - E
>   /
> A  - C - F - B' - D' - E'
>
> Which after dcommitting, git-updating, and merging will look like:
>
>     B       -        D      -      E
>   /                                  /
> A  - C - F - B" - D" - E"
>
> Which is a better reflection of history and has less chance of references
> getting screwed up. On the other hand, you have to make sure that your
> checked out on trunk at E' when you dcommit (or say `git svn dcommit
> trunk`) or you'll wind up dcommitting your feature branch to subversion,
> which will make a bit of a mess.
>
Cherry picking does look like a good alternative.

But in my opinion the actual thing that allowed me to make my mess is that
github and svn can be out of sync for 4 hours. If you run a git-update during
that time it can have a backwards effect if your local git and svn are more
recent than github. My mistake is not avoided by using either cherry-pick or
using rebase, because a git-update with an out of sync git-hub resets your
(more recent) trunk from underneath you.

If at all possible, I would recommend to initiate the sync action as part of
an svn post-commit hook. I realize this may not be easy because two different
people manage the involved repos on independent servers.

Geert
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: git-svn and local feature branch (git svn dcommit error ?)

John Ralls-2

On May 24, 2011, at 1:04 AM, Geert Janssens wrote:

> On maandag 23 mei 2011, John Ralls wrote:
>> On May 22, 2011, at 12:54 PM, Christian Stimming wrote:
>>> Am Sonntag, 22. Mai 2011 schrieb John Ralls:
>>>> The procedure in the Wiki page is what I think is correct (and what I've
>>>> done).
>>>>
>>>> It's perfectly normal in git to get part of a complicated feature done
>>>> and copy that bit to the main branch (trunk for us, but "master" is the
>>>> usual name in git repos) and then to keep working on the feature
>>>> branch. In that case one should periodically merge the main branch into
>>>> the feature branch
>>>
>>> Yes, absolutely, for the normal git workflow.
>>>
>>> However, here we are talking about the git-svn branch from which we want
>>> to
>>>
>>> dcommit to SVN. The IMHO unexpected part here is this:
>>>> git checkout trunk
>>>> git rebase feature
>>>> git svn dcommit
>>>
>>> I.e. why is the "trunk" rebased on top of the "feature" branch, then
>>> being d- committed? Either all of the feature branch should go into SVN,
>>> in which case I would rebase "feature" on top of "trunk" (i.e. the other
>>> way round compared to the above steps). Or the "feature" commits should
>>> not (yet) be committed, in which case I would do
>>>
>>>> git checkout feature
>>>> git merge trunk
>>>
>>> and then occasionally cherry-pick some of "feature"'s commits into trunk
>>> and d-commit from there. In the end, I would again rebase "feature" on
>>> top of "trunk" and this way d-commit all the commits that haven't been
>>> cherry-picked to trunk before.
>>>
>>> I agree this "git merge trunk" is written in the end of this new section,
>>> and that's what I have expected. But the "git rebase feature" still
>>> looks unexpected to me.
>>
>> Sorry, you're right. I got the direction of rebase backwards. So it should
>> be
>>
>> git checkout feature
>> git rebase trunk
>> (Or just `git rebase trunk feature` which does both steps at once)
>> git svn dcommit
>>
> Right, that is what I have been doing all the time and why I was surprised
> about your setup. But considering my limited experience with git, I was
> willing to follow your workflow.
>
>> You're probably right about cherry-picking, too. (You can cherry-pick all
>> of the changes at once with `git cherry-pick ..trunk` when checked out in
>> feature.) Rebasing might have contributed to Geert's remote refs getting
>> messed up.
>>
> Yes, I think so too. And particularly rebasing while the two remotes involved
> (svn and John's github master repo) are not in sync.
> As said before, I wanted to dcommit two separate feature branches right one
> after the other. They were both rebased to the actual remote trunk just before
> I started the process of dcomitting.
>
>    B - D - E      Feature 1
>  /
> A                  Trunk (both local and remote)
>  \
>    G              Feature 2
>
>
> The first dcommit worked fine:
>
>    B' - D' - E'      Feature 1, Trunk local, Trunk svn
>  /
> A                  Trunk github
>  \
>    G              Feature 2
>
> At that point I got unsure. Just to be sure I now ran git-update, which
> resulted in this:
>
>    B' - D' - E'      Feature 1, Trunk svn
>  /
> A                  Trunk github, Trunk local
>  \
>    G              Feature 2
>
> And I think that was a mistake. Github hadn't synched yet with subversion, so
> it rebased trunk back to the github's trunk, while svn's trunk was pointing to
> my feature 1. Perhaps internally, this also messed up git-svn's state, I can't
> tell.
>
> Assuming I should always commit to trunk, and my Feature 2 branch was again
> based on trunk due to the git-update action, I continued to dcommit Feature 2.
> This worked fine, although I don't know exactly what the new state became.
>
> After that I didn't do anything anymore until after the next github svn sync.
> And from there on, I got the issues I reported.
>
> I now think I would have avoided these problems if I didn't run the git-update
> command in between the two dcommits. Instead I should have rebased feature 2
> on top of feature 1. Wether I'd have done that before or after the first
> dcommit is probably not really important.
>
>> Starting with
>>     B - D - E Feature
>>  /
>> A  - C - F Trunk
>>
>> Rebasing does this:
>>
>>                 B' - D' - E'
>>               /
>> A - C- F
>>
>> If you dcommit with E' checked out (which is where you'll be after the
>> rebase), Github:Gnucash/gnucash will see
>>
>> A - C - F - B" - D" - E"
>>
> ...that is, after the next time github and svn are synched together.
>
>> When you run git-update you'll have
>>
>>                  B' - D' - E'
>>               /
>> A - C - F - B" - D" - E"
>>
> Again, only if you wait until after the next sync. If you don't wait before
> running git-update, your local trunk will be dissociated from git-svn's trunk
> and be reset to F.

The spacing got messed up here because I forgot to force a monospace font in mail.
It should look like:
          B' - D' - E'
         /
A - C - F - B" - D" - E"

I've adjusted the following ones so that the branches line up correctly:

>
>> And a merge will adjust your references to
>>

          B'  -  D'  -  E'
         /             /
A - C - F - B" - D" - E"
>
>> On the other hand, cherry-picking the whole thing will produce
>>
   B - D - E
 /
A  - C - F - B' - D' - E'
>
>> Which after dcommitting, git-updating, and merging will look like:
>>

   B    -    D     -     E
 /                      /
A  - C - F - B" - D" - E"

>>
>> Which is a better reflection of history and has less chance of references
>> getting screwed up. On the other hand, you have to make sure that your
>> checked out on trunk at E' when you dcommit (or say `git svn dcommit
>> trunk`) or you'll wind up dcommitting your feature branch to subversion,
>> which will make a bit of a mess.
>>
> Cherry picking does look like a good alternative.
>
> But in my opinion the actual thing that allowed me to make my mess is that
> github and svn can be out of sync for 4 hours. If you run a git-update during
> that time it can have a backwards effect if your local git and svn are more
> recent than github. My mistake is not avoided by using either cherry-pick or
> using rebase, because a git-update with an out of sync git-hub resets your
> (more recent) trunk from underneath you.
>
> If at all possible, I would recommend to initiate the sync action as part of
> an svn post-commit hook. I realize this may not be easy because two different
> people manage the involved repos on independent servers.

We could set up signaling somehow, but it would be easier to just move the whole thing to Code. Derek?

In the meantime, I'll increase the frequency of updates.

Regards,
John Ralls

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: git-svn and local feature branch (git svn dcommit error ?)

Derek Atkins
John Ralls <[hidden email]> writes:

>> If at all possible, I would recommend to initiate the sync action as
>> part of an svn post-commit hook. I realize this may not be easy
>> because two different people manage the involved repos on independent
>> servers.
>
> We could set up signaling somehow, but it would be easier to just move
> the whole thing to Code. Derek?

Either is possible.  We could set up a port-knocker to signal you when
there's an SVN commit.  (We already do this to update www when htdocs
gets updated).

As for moving the whole thing to Code, I think it would be better to
wait until Code gets updated to a more recent version of the OS.  It's
currently running Fedora 10.  Fedora 15 was just released today.  I
should have time to actually update the system starting next week so I
can schedule the maintenance.  It will require several hours of downtime
to perform the upgrades.

Once I perform the upgrade we could move the git sync to the server.
Down the road we could still consider migrating from SVN to GIT
completely?

> In the meantime, I'll increase the frequency of updates.

Or we could set up the port knocker (which I could do sooner).

> Regards,
> John Ralls

-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
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: git-svn and local feature branch (git svn dcommit error ?)

John Ralls-2

On May 24, 2011, at 8:33 AM, Derek Atkins wrote:

> John Ralls <[hidden email]> writes:
>
>>> If at all possible, I would recommend to initiate the sync action as
>>> part of an svn post-commit hook. I realize this may not be easy
>>> because two different people manage the involved repos on independent
>>> servers.
>>
>> We could set up signaling somehow, but it would be easier to just move
>> the whole thing to Code. Derek?
>
> Either is possible.  We could set up a port-knocker to signal you when
> there's an SVN commit.  (We already do this to update www when htdocs
> gets updated).
>
> As for moving the whole thing to Code, I think it would be better to
> wait until Code gets updated to a more recent version of the OS.  It's
> currently running Fedora 10.  Fedora 15 was just released today.  I
> should have time to actually update the system starting next week so I
> can schedule the maintenance.  It will require several hours of downtime
> to perform the upgrades.
>
> Once I perform the upgrade we could move the git sync to the server.
> Down the road we could still consider migrating from SVN to GIT
> completely?
>
I think Geert, Christian, and I are ready to do that now. Not sure about the others. Perhaps you'd want to do that as part of upgrading Code?

>> In the meantime, I'll increase the frequency of updates.
>
> Or we could set up the port knocker (which I could do sooner).

What kind of listener will I need?

Regards,
John Ralls
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: git-svn and local feature branch (git svn dcommit error ?)

Derek Atkins
John Ralls <[hidden email]> writes:

>> Once I perform the upgrade we could move the git sync to the server.
>> Down the road we could still consider migrating from SVN to GIT
>> completely?
>>
> I think Geert, Christian, and I are ready to do that now. Not sure
> about the others. Perhaps you'd want to do that as part of upgrading
> Code?

Well, we'd have to update all the build scripts (both on the server and
elsewhere) to build from git instead of building from SVN.  This
includes (but is not limited to):

* doxygen source-docs build
* gnucash-docs build
* win32 build
* www (This is one place that might be more challenging!)

Moreover, we would need to consider the security ramifications of a git
push into a repo on code.gnucash.org.

I think that upgrading Code to a more recent OS is a necessary step, but
the migration from SVN -> GIT can happen afterwards.

>>> In the meantime, I'll increase the frequency of updates.
>>
>> Or we could set up the port knocker (which I could do sooner).
>
> What kind of listener will I need?

We can discuss that offline, but basically the port knocker just
contacts your host via TCP on an agreed-upon port and sends an
agreed-upon string.  Your host can then use that to fire off a sync.

Note that if there are multiple SVN commits in quick succession then you
might get multiple sync calls that you'll need to synchronize (unless
git does that automatically).

> Regards,
> John Ralls

-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
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: git-svn and local feature branch (git svn dcommit error ?)

John Ralls-2

On May 24, 2011, at 8:57 AM, Derek Atkins wrote:

> John Ralls <[hidden email]> writes:
>
>>> Once I perform the upgrade we could move the git sync to the server.
>>> Down the road we could still consider migrating from SVN to GIT
>>> completely?
>>>
>> I think Geert, Christian, and I are ready to do that now. Not sure
>> about the others. Perhaps you'd want to do that as part of upgrading
>> Code?
>
> Well, we'd have to update all the build scripts (both on the server and
> elsewhere) to build from git instead of building from SVN.  This
> includes (but is not limited to):
>
> * doxygen source-docs build
> * gnucash-docs build
> * win32 build
> * www (This is one place that might be more challenging!)
>
> Moreover, we would need to consider the security ramifications of a git
> push into a repo on code.gnucash.org.
>
> I think that upgrading Code to a more recent OS is a necessary step, but
> the migration from SVN -> GIT can happen afterwards.
OK. I hadn't thought about the scripts. Git can deal with ssh, that's how Gnome does it, so security shouldn't be any more of a problem than with svn.

Regards,
John Ralls

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: git-svn and local feature branch (git svn dcommit error ?)

Derek Atkins
John Ralls <[hidden email]> writes:

>> I think that upgrading Code to a more recent OS is a necessary step, but
>> the migration from SVN -> GIT can happen afterwards.
>
> OK. I hadn't thought about the scripts. Git can deal with ssh, that's how Gnome does it, so security shouldn't be any more of a problem than with svn.

Is there the concept of pre-commit and post-commit hooks (similar to
svn) in order to implement access control and "perform this post-commit
operation" hooks?

I've never set up a git server repository so I have no experience there.

> Regards,
> John Ralls

-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
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: git-svn and local feature branch (git svn dcommit error ?)

Jim Paris
Derek Atkins wrote:

> John Ralls <[hidden email]> writes:
>
> >> I think that upgrading Code to a more recent OS is a necessary step, but
> >> the migration from SVN -> GIT can happen afterwards.
> >
> > OK. I hadn't thought about the scripts. Git can deal with ssh, that's how Gnome does it, so security shouldn't be any more of a problem than with svn.
>
> Is there the concept of pre-commit and post-commit hooks (similar to
> svn) in order to implement access control and "perform this post-commit
> operation" hooks?
>
> I've never set up a git server repository so I have no experience there.

Yeah, see http://www.kernel.org/pub/software/scm/git/docs/githooks.html
These hooks are set up on the bare repository on the server and are
just like svn hooks.

Hooks are executed if you pushing through git protocol or smart HTTP.
Dumb (WebDAV) HTTP doesn't execute them but there's no reason to run
that.

-jim



_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
12