After reading in a separate thread that Eric was having trouble with
svnmerge, I gave it a try and got
jdhunter@...687...:mpl> svnmerge.py merge v0_98_5_maint
svnmerge: "v0_98_5_maint" is not a subversion working directory
Maybe our svn merge guru (MD) could take a look and see if anything
looks out of whack?
JDH
John Hunter wrote:
After reading in a separate thread that Eric was having trouble with
svnmerge, I gave it a try and gotjdhunter@...687...:mpl> svnmerge.py merge v0_98_5_maint
svnmerge: "v0_98_5_maint" is not a subversion working directoryMaybe our svn merge guru (MD) could take a look and see if anything
looks out of whack?
John,
I don't understand exactly what was going on, but I suspect there may have been two or more problems--especially since you seem to have run into the same error message that I was getting.
One problem, I think, is that I was trying to run svnmerge from a subdirectory instead of from the root of my checkout. I simply did not notice that I was in the wrong directory until I had thrashed around for a while.
There may be, or have been, a larger problem as well--maybe caused by me, maybe not. In any case, to get things working, I reran
svnmerge init matplotlib download | SourceForge.net
but it looks like I was still in the wrong directory when I did that, so I don't know if it had any useful effect.
After getting into the right directory, some combination of svn up and svnmerge merge seemed to get everything straightened out, with a little editing to resolve conflicts along the way.
That was last night, in the misty past. Now it looks like I am back with the original problem I started with last night, and which you also reported:
efiring@...340...:~/programs/py/mpl/mpl_trunk$ svnmerge avail /branches/v0_98_5_maint
svnmerge: "/branches/v0_98_5_maint" is not a subversion working directory
So, I'm baffled again. It is as if Jae-Joon's commit since mine of last night, and my corresponding "svn up" this morning, wiped out the svnmerge tracking info.
I suspect a brief wave of Mike's magic wand tomorrow morning will clear away the fog.
Eric
You need the '-S' parameter to specify a branch. Otherwise, any arguments after the command name are just paths within the working copy, just like most other svn commands.
So you need to do:
svnmerge.py merge -S v0_98_5_maint
I just tested a change to the branch followed by a merge and everything seems to be working fine here.
Eric Firing wrote:
John Hunter wrote:
svnmerge init matplotlib download | SourceForge.net
That would have no effect without a following commit anyway... but please don't do that if you're not sure what you're doing. That command really should only ever be needed once. It's pretty hard to get into a state where it would ever need to be done again for a particular branch.
but it looks like I was still in the wrong directory when I did that, so I don't know if it had any useful effect.
After getting into the right directory, some combination of svn up and svnmerge merge seemed to get everything straightened out, with a little editing to resolve conflicts along the way.
You can do merges from within subdirectories, and it works just like most other svn commands when run from a subdirectory. Generally, though, I like to catch all available merges and run from the root of the source tree.
That was last night, in the misty past. Now it looks like I am back with the original problem I started with last night, and which you also reported:
efiring@...340...:~/programs/py/mpl/mpl_trunk$ svnmerge avail /branches/v0_98_5_maint
svnmerge: "/branches/v0_98_5_maint" is not a subversion working directory
Again, you're specifying a path that doesn't exist within the source tree. There is no need to specify a path (generally) with the "svnmerge avail" command.
So, I'm baffled again. It is as if Jae-Joon's commit since mine of last night, and my corresponding "svn up" this morning, wiped out the svnmerge tracking info.
I suspect a brief wave of Mike's magic wand tomorrow morning will clear away the fog.
I think this all comes down to missing the '-S'. I didn't need to get out my wand for this one... 
Mike
Michael Droettboom wrote:
You need the '-S' parameter to specify a branch. Otherwise, any arguments after the command name are just paths within the working copy, just like most other svn commands.
So you need to do:
svnmerge.py merge -S v0_98_5_maint
I just tested a change to the branch followed by a merge and everything seems to be working fine here.
Eric Firing wrote:
John Hunter wrote:
svnmerge init matplotlib download | SourceForge.netThat would have no effect without a following commit anyway... but please don't do that if you're not sure what you're doing. That command really should only ever be needed once. It's pretty hard to get into a state where it would ever need to be done again for a particular branch.
but it looks like I was still in the wrong directory when I did that, so I don't know if it had any useful effect.
After getting into the right directory, some combination of svn up and svnmerge merge seemed to get everything straightened out, with a little editing to resolve conflicts along the way.
You can do merges from within subdirectories, and it works just like most other svn commands when run from a subdirectory. Generally, though, I like to catch all available merges and run from the root of the source tree.
That was last night, in the misty past. Now it looks like I am back with the original problem I started with last night, and which you also reported:
efiring@...340...:~/programs/py/mpl/mpl_trunk$ svnmerge avail /branches/v0_98_5_maint
svnmerge: "/branches/v0_98_5_maint" is not a subversion working directory
Again, you're specifying a path that doesn't exist within the source tree. There is no need to specify a path (generally) with the "svnmerge avail" command.
So, I'm baffled again. It is as if Jae-Joon's commit since mine of last night, and my corresponding "svn up" this morning, wiped out the svnmerge tracking info.
I suspect a brief wave of Mike's magic wand tomorrow morning will clear away the fog.
I think this all comes down to missing the '-S'. I didn't need to get out my wand for this one...
Well, looking back at the command history in the terminal window I was using, I was using the -S last night when things first started going haywire; but one way or another, or many ways, I was getting confused.
Thanks for the clarifications and testing.
Eric