svnmerge.py - keeping the maintenance branch and trunk in sync

I have been as guilty as anyone at this, but I think it will be good
for us to be careful to keep the branch and trunk in sync vis-a-vis
bugfixes where it makes sense as much as is possible. To date, I have
been fixing them in one place or another and Michael has been doing a
good job merging things in, but we should all try and help him in
these efforts. I have updated the CODING_GUIDE (in the branch and
merged onto the trunk, woohoo!) with instructions. Here they are:

  * Keep the maintenance branch and trunk in sync where it makes sense.
    If there is a bug on both that needs fixing, use svnmerge.py to
    keep them in sync. http://www.orcaware.com/svn/wiki/Svnmerge.py. The
    basic procedure is:

      - install svnmerge.py in your PATH

      - get a svn copy of the branch (svn co
        https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v0_91_maint)
        and the trunk (svn co
        https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib)

      - Michael advises making the change on the branch and committing
        it. Make sure you svn upped on the trunk and have no local
        modifications, and then from the svn trunk do

  # where the NNN are the revision numbers. ranges also acceptable
        > svnmerge.py merge -rNNN1,NNN2

  # this file is automatically created by the merge command

···

svn commit -F svnmerge-commit-message.txt

ichael -- what if someone has already made a change on the trunk and
wants to merge it to the branch with svnmerge? What is the
recommended way to do this? Can they simply go to the branch and do
'svnmerge.py merge'?

JDH

···

On Sat, May 17, 2008 at 4:40 PM, John Hunter <jdh2358@...149...> wrote:

     - Michael advises making the change on the branch and committing
       it. Make sure you svn upped on the trunk and have no local
       modifications, and then from the svn trunk do

I haven't initialized it for that direction. In a lot of ways, svnmerge is far less useful in that case because there are many more things going on the trunk that you don't want in the branch than vice versa.

I think in this case, a vanilla 'svn merge' (i.e. not using svnmerge.py) is probably going to be easier.

See here http://svnbook.red-bean.com/en/1.4/svn.branchmerge.copychanges.html

Cheers,
Mike

John Hunter wrote:

···

On Sat, May 17, 2008 at 4:40 PM, John Hunter <jdh2358@...149...> wrote:

     - Michael advises making the change on the branch and committing
       it. Make sure you svn upped on the trunk and have no local
       modifications, and then from the svn trunk do
    
ichael -- what if someone has already made a change on the trunk and
wants to merge it to the branch with svnmerge? What is the
recommended way to do this? Can they simply go to the branch and do
'svnmerge.py merge'?

JDH

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I am trying to merge a change to texmanager from the branch to the trunk, but
something doesnt look right after I ran svnmerge.py. Look at all the markup
in the diff, I can't commit this, can I?

$ svn diff

Property changes on: .

···

___________________________________________________________________
Modified: svnmerge-integrated
   - /branches/v0_91_maint:1-5294
   + /branches/v0_91_maint:1-5294,5299

Index: CHANGELOG

--- CHANGELOG (revision 5299)
+++ CHANGELOG (working copy)
@@ -1,3 +1,13 @@
+<<<<<<< .working
+=======
+2008-05-29 Fixed two bugs in texmanager.py:
+ improved comparison of dvipng versions
+ fixed a bug introduced when get_grey method was added
+ - DSD
+
+2008-05-29 Implement path clipping in SVG backend - MGD
+
+>>>>>>> .merge-right.r5299
2008-05-28 Fix crashing of PDFs in xpdf and ghostscript when two-byte
            characters are used with Type 3 fonts - MGD

Index: lib/matplotlib/texmanager.py

--- lib/matplotlib/texmanager.py (revision 5299)
+++ lib/matplotlib/texmanager.py (working copy)
@@ -33,8 +33,14 @@

"""

+<<<<<<< .working
import copy, glob, md5, os, shutil, sys
import numpy as np
+=======
+import copy, glob, md5, os, shutil, sys, warnings
+import distutils.version
+import numpy as npy
+>>>>>>> .merge-right.r5299
import matplotlib as mpl
from matplotlib import rcParams
from matplotlib._image import readpng
@@ -44,14 +50,15 @@
if sys.platform.startswith('win'): cmd_split = '&'
else: cmd_split = ';'

-def get_dvipng_version():
+def dvipng_hack_alpha():
     stdin, stdout = os.popen4('dvipng -version')
     for line in stdout:
         if line.startswith('dvipng '):
             version = line.split()[-1]
             mpl.verbose.report('Found dvipng version %s'% version,
                 'helpful')
- return version
+ version = distutils.version.LooseVersion(version)
+ return version < distutils.version.LooseVersion('1.6')
     raise RuntimeError('Could not obtain dvipng version')

@@ -78,7 +85,7 @@
     if not os.path.exists(texcache):
         os.mkdir(texcache)

- dvipngVersion = get_dvipng_version()
+ _dvipng_hack_alpha = dvipng_hack_alpha()

     # mappable cache of
     rgba_arrayd = {}
@@ -364,8 +371,28 @@
             pngfile = self.make_png(tex, fontsize, dpi)
             X = readpng(os.path.join(self.texcache, pngfile))

- if (self.dvipngVersion < '1.6') or rcParams['text.dvipnghack']:
- # hack the alpha channel as described in comment above
+ if self._dvipng_hack_alpha or rcParams['text.dvipnghack']:
+ # hack the alpha channel
+ # dvipng assumed a constant background, whereas we want to
+ # overlay these rasters with antialiasing over arbitrary
+ # backgrounds that may have other figure elements under them.
+ # When you set dvipng -bg Transparent, it actually makes the
+ # alpha channel 1 and does the background compositing and
+ # antialiasing itself and puts the blended data in the rgb
+ # channels. So what we do is extract the alpha information
+ # from the red channel, which is a blend of the default
dvipng
+ # background (white) and foreground (black). So the amount
of
+ # red (or green or blue for that matter since white and black
+ # blend to a grayscale) is the alpha intensity. Once we
+ # extract the correct alpha information, we assign it to the
+ # alpha channel properly and let the users pick their rgb.
In
+ # this way, we can overlay tex strings on arbitrary
+ # backgrounds with antialiasing
+ #
+ # red = alpha*red_foreground + (1-alpha)*red_background
+ #
+ # Since the foreground is black (0) and the background is
+ # white (1) this reduces to red = 1-alpha or alpha = 1-red
                 alpha = np.sqrt(1-X[:,:,0])
             else:
                 alpha = X[:,:,-1]
@@ -378,26 +405,6 @@
         """
         Returns latex's rendering of the tex string as an rgba array
         """
- # dvipng assumes a constant background, whereas we want to
- # overlay these rasters with antialiasing over arbitrary
- # backgrounds that may have other figure elements under them.
- # When you set dvipng -bg Transparent, it actually makes the
- # alpha channel 1 and does the background compositing and
- # antialiasing itself and puts the blended data in the rgb
- # channels. So what we do is extract the alpha information
- # from the red channel, which is a blend of the default dvipng
- # background (white) and foreground (black). So the amount of
- # red (or green or blue for that matter since white and black
- # blend to a grayscale) is the alpha intensity. Once we
- # extract the correct alpha information, we assign it to the
- # alpha channel properly and let the users pick their rgb. In
- # this way, we can overlay tex strings on arbitrary
- # backgrounds with antialiasing
- #
- # red = alpha*red_foreground + (1-alpha)*red_background
- #
- # Since the foreground is black (0) and the background is
- # white (1) this reduces to red = 1-alpha or alpha = 1-red
         if not fontsize: fontsize = rcParams['font.size']
         if not dpi: dpi = rcParams['savefig.dpi']
         r,g,b = rgb
@@ -407,7 +414,11 @@
         if Z is None:
             alpha = self.get_grey(tex, fontsize, dpi)

+<<<<<<< .working
             Z = np.zeros((X.shape[0], X.shape[1], 4), np.float)
+=======
+ Z = npy.zeros((alpha.shape[0], alpha.shape[1], 4), npy.float)
+>>>>>>> .merge-right.r5299
             Z[:,:,0] = r
             Z[:,:,1] = g
             Z[:,:,2] = b

I am trying to merge a change to texmanager from the branch to the trunk, but
something doesnt look right after I ran svnmerge.py. Look at all the markup
in the diff, I can't commit this, can I?

No. The > +<<<<<<< .working stuff means there are conflicts in the
merge between the branch and trunk, and you have to resolve them by
editing all the files which have conflicts to resolve the conflicts,
and then clean up all the conflict files, eg CHANGELOG.r5299 and stuff
like that, and then commit the fixed files.

···

On Thu, May 29, 2008 at 9:01 AM, Darren Dale <darren.dale@...143...> wrote:

$ svn diff

Property changes on: .
___________________________________________________________________
Modified: svnmerge-integrated
  - /branches/v0_91_maint:1-5294
  + /branches/v0_91_maint:1-5294,5299

Index: CHANGELOG

--- CHANGELOG (revision 5299)
+++ CHANGELOG (working copy)
@@ -1,3 +1,13 @@
+<<<<<<< .working
+=======
+2008-05-29 Fixed two bugs in texmanager.py:
+ improved comparison of dvipng versions
+ fixed a bug introduced when get_grey method was added
+ - DSD
+
+2008-05-29 Implement path clipping in SVG backend - MGD
+
+>>>>>>> .merge-right.r5299
2008-05-28 Fix crashing of PDFs in xpdf and ghostscript when two-byte
           characters are used with Type 3 fonts - MGD

Index: lib/matplotlib/texmanager.py

--- lib/matplotlib/texmanager.py (revision 5299)
+++ lib/matplotlib/texmanager.py (working copy)
@@ -33,8 +33,14 @@

"""

+<<<<<<< .working
import copy, glob, md5, os, shutil, sys
import numpy as np
+=======
+import copy, glob, md5, os, shutil, sys, warnings
+import distutils.version
+import numpy as npy
+>>>>>>> .merge-right.r5299
import matplotlib as mpl
from matplotlib import rcParams
from matplotlib._image import readpng
@@ -44,14 +50,15 @@
if sys.platform.startswith('win'): cmd_split = '&'
else: cmd_split = ';'

-def get_dvipng_version():
+def dvipng_hack_alpha():
    stdin, stdout = os.popen4('dvipng -version')
    for line in stdout:
        if line.startswith('dvipng '):
            version = line.split()[-1]
            mpl.verbose.report('Found dvipng version %s'% version,
                'helpful')
- return version
+ version = distutils.version.LooseVersion(version)
+ return version < distutils.version.LooseVersion('1.6')
    raise RuntimeError('Could not obtain dvipng version')

@@ -78,7 +85,7 @@
    if not os.path.exists(texcache):
        os.mkdir(texcache)

- dvipngVersion = get_dvipng_version()
+ _dvipng_hack_alpha = dvipng_hack_alpha()

    # mappable cache of
    rgba_arrayd = {}
@@ -364,8 +371,28 @@
            pngfile = self.make_png(tex, fontsize, dpi)
            X = readpng(os.path.join(self.texcache, pngfile))

- if (self.dvipngVersion < '1.6') or rcParams['text.dvipnghack']:
- # hack the alpha channel as described in comment above
+ if self._dvipng_hack_alpha or rcParams['text.dvipnghack']:
+ # hack the alpha channel
+ # dvipng assumed a constant background, whereas we want to
+ # overlay these rasters with antialiasing over arbitrary
+ # backgrounds that may have other figure elements under them.
+ # When you set dvipng -bg Transparent, it actually makes the
+ # alpha channel 1 and does the background compositing and
+ # antialiasing itself and puts the blended data in the rgb
+ # channels. So what we do is extract the alpha information
+ # from the red channel, which is a blend of the default
dvipng
+ # background (white) and foreground (black). So the amount
of
+ # red (or green or blue for that matter since white and black
+ # blend to a grayscale) is the alpha intensity. Once we
+ # extract the correct alpha information, we assign it to the
+ # alpha channel properly and let the users pick their rgb.
In
+ # this way, we can overlay tex strings on arbitrary
+ # backgrounds with antialiasing
+ #
+ # red = alpha*red_foreground + (1-alpha)*red_background
+ #
+ # Since the foreground is black (0) and the background is
+ # white (1) this reduces to red = 1-alpha or alpha = 1-red
                alpha = np.sqrt(1-X[:,:,0])
            else:
                alpha = X[:,:,-1]
@@ -378,26 +405,6 @@
        """
        Returns latex's rendering of the tex string as an rgba array
        """
- # dvipng assumes a constant background, whereas we want to
- # overlay these rasters with antialiasing over arbitrary
- # backgrounds that may have other figure elements under them.
- # When you set dvipng -bg Transparent, it actually makes the
- # alpha channel 1 and does the background compositing and
- # antialiasing itself and puts the blended data in the rgb
- # channels. So what we do is extract the alpha information
- # from the red channel, which is a blend of the default dvipng
- # background (white) and foreground (black). So the amount of
- # red (or green or blue for that matter since white and black
- # blend to a grayscale) is the alpha intensity. Once we
- # extract the correct alpha information, we assign it to the
- # alpha channel properly and let the users pick their rgb. In
- # this way, we can overlay tex strings on arbitrary
- # backgrounds with antialiasing
- #
- # red = alpha*red_foreground + (1-alpha)*red_background
- #
- # Since the foreground is black (0) and the background is
- # white (1) this reduces to red = 1-alpha or alpha = 1-red
        if not fontsize: fontsize = rcParams['font.size']
        if not dpi: dpi = rcParams['savefig.dpi']
        r,g,b = rgb
@@ -407,7 +414,11 @@
        if Z is None:
            alpha = self.get_grey(tex, fontsize, dpi)

+<<<<<<< .working
            Z = np.zeros((X.shape[0], X.shape[1], 4), np.float)
+=======
+ Z = npy.zeros((alpha.shape[0], alpha.shape[1], 4), npy.float)
+>>>>>>> .merge-right.r5299
            Z[:,:,0] = r
            Z[:,:,1] = g
            Z[:,:,2] = b

I dont understand. I thought the point of svnmerge.py was to sync the change,
not to introduce conflicts. Is the procedure you just outlined the standard
operating procedure, or did svnmerge.py encounter problems? The procedure in
your original post to this thread seems much more straight forward.

Say I attempt to resolve conflicts, do I then run svnmerge.py again to make
sure that no additional conflicts are introduced? (arg, hg and bzr make this
much easier.)

···

On Thursday 29 May 2008 10:04:34 am you wrote:

On Thu, May 29, 2008 at 9:01 AM, Darren Dale <darren.dale@...143...> wrote:
> I am trying to merge a change to texmanager from the branch to the trunk,
> but something doesnt look right after I ran svnmerge.py. Look at all the
> markup in the diff, I can't commit this, can I?

No. The > +<<<<<<< .working stuff means there are conflicts in the
merge between the branch and trunk, and you have to resolve them by
editing all the files which have conflicts to resolve the conflicts,
and then clean up all the conflict files, eg CHANGELOG.r5299 and stuff
like that, and then commit the fixed files.

I'm sorry, I just don't understand how to use this. I just got a clean
checkout of the trunk, ran "svnmerge.py merge":

$ svnmerge.py merge
property 'svnmerge-integrated' set on '.'

property 'svnmerge-blocked' deleted from '.'.

--- Merging r5298 through r5299 into '.':
U CHANGELOG
C lib/matplotlib/texmanager.py
C lib/matplotlib/backends/backend_svg.py

property 'svnmerge-integrated' set on '.'

property 'svnmerge-blocked' deleted from '.'.

Thats not what I want, I only want to commit the changes I made to CHANGELOG
and texmanager. I tried reverting the changes with svn revert, but now when I
do a diff, I get:

$ svn diff

Property changes on: .

···

On Thursday 29 May 2008 10:15:07 am John Hunter wrote:

On Thu, May 29, 2008 at 9:11 AM, Darren Dale <darren.dale@...143...> wrote:
> I dont understand. I thought the point of svnmerge.py was to sync the
> change, not to introduce conflicts. Is the procedure you just outlined
> the standard operating procedure, or did svnmerge.py encounter problems?
> The procedure in your original post to this thread seems much more
> straight forward.

I think the point is to keep track of which revisions you've already
merged (and resolved conflicts in) so you don't have to resolve them
again later. Michale pointed out to me offlist that in standard
usage, you do not need to manually give the revision number so my
original instructions advocating them were wrong.

___________________________________________________________________
Modified: svnmerge-integrated
   - /branches/v0_91_maint:1-5294
   + /branches/v0_91_maint:1-5299

Can I please just manually merge my changes in from the branch, without
svnmerge.py? I really don't have time today to mess around with this.

Darren

I already screwed up everything once royally, so I'll let Michael
comment on this.

···

On Thu, May 29, 2008 at 9:41 AM, Darren Dale <darren.dale@...143...> wrote:

Thats not what I want, I only want to commit the changes I made to CHANGELOG
and texmanager. I tried reverting the changes with svn revert, but now when I
do a diff, I get:

$ svn diff

Property changes on: .
___________________________________________________________________
Modified: svnmerge-integrated
  - /branches/v0_91_maint:1-5294
  + /branches/v0_91_maint:1-5299

Darren Dale wrote:

  

I am trying to merge a change to texmanager from the branch to the trunk,
but something doesnt look right after I ran svnmerge.py. Look at all the
markup in the diff, I can't commit this, can I?
      

No. The > +<<<<<<< .working stuff means there are conflicts in the
merge between the branch and trunk, and you have to resolve them by
editing all the files which have conflicts to resolve the conflicts,
and then clean up all the conflict files, eg CHANGELOG.r5299 and stuff
like that, and then commit the fixed files.
    

Minor point: On my machine at least, I don't have to manually clean up the conflict files -- they are removed for me on the next commit. Those files are really just for reference. If you use a SVN frontend for diffing (such as psvn.el or meld) they are largely unnecessary.

I dont understand. I thought the point of svnmerge.py was to sync the change, not to introduce conflicts. Is the procedure you just outlined the standard operating procedure, or did svnmerge.py encounter problems? The procedure in your original post to this thread seems much more straight forward.
  Say I attempt to resolve conflicts, do I then run svnmerge.py again to make sure that no additional conflicts are introduced? (arg, hg and bzr make this much easier.)
  

You don't need to run svnmerge.py again. You just need to resolve the conflicts, removing the conflict markers, tell SVN you have done so (with "svn resolved"), and then commit ("svn commit -F svnmerge-commit-message.txt").

There are differences in the branch and trunk (sometimes called "version drift") that make it impossible to merge the files automatically. This is an oft cited advantage of hg and bzr, but I don't think any tool that doesn't do some sort of deep code introspection could help out here. When people say "merging is easier with tool X", they usually mean that the branch/merge tracking is better, not that it can resolve conflicts any "smarter." SVN proper has virtually no branch/merge tracking, svnmerge makes things a little better, but not very well integrated. But as for conflicts, according to the bzr manpage, bzr appears to do exactly the same thing as SVN in this case, including the creation of three extra files (though the details are different):

http://doc.bazaar-vcs.org/bzr-0.10/bzr_man.htm#id17

For instance, look at the last difference:

@@ -407,7 +414,11 @@
         if Z is None:
             alpha = self.get_grey(tex, fontsize, dpi)

+<<<<<<< .working
             Z = np.zeros((X.shape[0], X.shape[1], 4), np.float)

···

On Thursday 29 May 2008 10:04:34 am you wrote:

On Thu, May 29, 2008 at 9:01 AM, Darren Dale <darren.dale@...143...> >> > wrote:

+=======
+ Z = npy.zeros((alpha.shape[0], alpha.shape[1], 4), npy.float)
+>>>>>>> .merge-right.r5299
             Z[:,:,0] = r
             Z[:,:,1] = g
             Z[:,:,2] = b

At one point, npy was renamed to np throughout this file, on the trunk, but not in the branch. SVN has no way of knowing (since it doesn't understand Python syntax) that these two tokens are equivalent. You need a human being who understands how the code is supposed to work to resolve this.

So, this is more the fault of operating procedure (choosing not to do the numpy renaming on the branch, for instance, which in itself was not a bad decision in isolation), than the tool itself. Note that svnmerge did do the right thing in your merge on about five diffs, and only two couldn't be automatically merged. In my own experience, merges work far more often than not, but as the trunk drifts further away from the branch, no doubt that percentage will go down...

Cheers,
Mike

Darren Dale wrote:

  

I dont understand. I thought the point of svnmerge.py was to sync the
change, not to introduce conflicts. Is the procedure you just outlined
the standard operating procedure, or did svnmerge.py encounter problems?
The procedure in your original post to this thread seems much more
straight forward.
      

I think the point is to keep track of which revisions you've already
merged (and resolved conflicts in) so you don't have to resolve them
again later. Michale pointed out to me offlist that in standard
usage, you do not need to manually give the revision number so my
original instructions advocating them were wrong.
    
I'm sorry, I just don't understand how to use this. I just got a clean checkout of the trunk, ran "svnmerge.py merge":

$ svnmerge.py merge
property 'svnmerge-integrated' set on '.'

property 'svnmerge-blocked' deleted from '.'.

--- Merging r5298 through r5299 into '.':
U CHANGELOG
C lib/matplotlib/texmanager.py
C lib/matplotlib/backends/backend_svg.py

property 'svnmerge-integrated' set on '.'

property 'svnmerge-blocked' deleted from '.'.

Thats not what I want, I only want to commit the changes I made to CHANGELOG and texmanager. I tried reverting the changes with svn revert, but now when I do a diff, I get:

$ svn diff

Property changes on: .
___________________________________________________________________
Modified: svnmerge-integrated
   - /branches/v0_91_maint:1-5294
   + /branches/v0_91_maint:1-5299

I'm confused by this. Did you do:

  svn -R revert .

from the root of the tree? That should back out that property change.

Can I please just manually merge my changes in from the branch, without svnmerge.py? I really don't have time today to mess around with this.
  

I can do the merge for you.

[mdroe@...603... matplotlib]$ svn update
U lib/matplotlib/ticker.py
U CHANGELOG
Updated to revision 5299.
[mdroe@...603... matplotlib]$ svnmerge merge
U CHANGELOG
C lib/matplotlib/texmanager.py
C lib/matplotlib/backends/backend_svg.py

property 'svnmerge-integrated' set on '.'

# We don't want to merge backend_svg.py -- we just want what's currently on the trunk
[mdroe@...603... matplotlib]$ cp lib/matplotlib/backends/backend_svg.py.working lib/matplotlib/backends/backend_svg.py

# Manually resolve texmanager.py
[mdroe@...603... matplotlib]$ emacs -nw lib/matplotlib/texmanager.py

# Mark everything as resolved
[mdroe@...603... matplotlib]$ svn -R resolved .
Resolved conflicted state of 'lib/matplotlib/backends/backend_svg.py'

# Commit
[mdroe@...603... matplotlib]$ svn commit -F svnmerge-commit-message.txt
Sending .
Sending CHANGELOG
Sending lib/matplotlib/texmanager.py
Transmitting file data ..
Committed revision 5300.
[mdroe@...603... matplotlib]$

Cheers,
Mike

···

On Thursday 29 May 2008 10:15:07 am John Hunter wrote:

On Thu, May 29, 2008 at 9:11 AM, Darren Dale <darren.dale@...143...> >> > wrote:

My (limited) experience has been same -- merges usually ""just work".
Part of the drift (eg the npy, np differences) we are currently
dealing with is explained by me doing things the wrong way for a
while, before I go. As more of us work to keep the branch in sync
where feasible, these kinds of problems should be less frequent.

JDH

···

On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <mdroe@...31...> wrote:

So, this is more the fault of operating procedure (choosing not to do the
numpy renaming on the branch, for instance, which in itself was not a bad
decision in isolation), than the tool itself. Note that svnmerge did do the
right thing in your merge on about five diffs, and only two couldn't be
automatically merged. In my own experience, merges work far more often than
not, but as the trunk drifts further away from the branch, no doubt that
percentage will go down...

Thanks Mike.

···

On Thursday 29 May 2008 10:59:40 am Michael Droettboom wrote:

Darren Dale wrote:
> On Thursday 29 May 2008 10:15:07 am John Hunter wrote:
>> On Thu, May 29, 2008 at 9:11 AM, Darren Dale <darren.dale@...143...> > > > > wrote:
>>> I dont understand. I thought the point of svnmerge.py was to sync the
>>> change, not to introduce conflicts. Is the procedure you just outlined
>>> the standard operating procedure, or did svnmerge.py encounter
>>> problems? The procedure in your original post to this thread seems much
>>> more straight forward.
>>
>> I think the point is to keep track of which revisions you've already
>> merged (and resolved conflicts in) so you don't have to resolve them
>> again later. Michale pointed out to me offlist that in standard
>> usage, you do not need to manually give the revision number so my
>> original instructions advocating them were wrong.
>
> I'm sorry, I just don't understand how to use this. I just got a clean
> checkout of the trunk, ran "svnmerge.py merge":
>
> $ svnmerge.py merge
> property 'svnmerge-integrated' set on '.'
>
> property 'svnmerge-blocked' deleted from '.'.
>
> --- Merging r5298 through r5299 into '.':
> U CHANGELOG
> C lib/matplotlib/texmanager.py
> C lib/matplotlib/backends/backend_svg.py
>
> property 'svnmerge-integrated' set on '.'
>
> property 'svnmerge-blocked' deleted from '.'.
>
> Thats not what I want, I only want to commit the changes I made to
> CHANGELOG and texmanager. I tried reverting the changes with svn revert,
> but now when I do a diff, I get:
>
> $ svn diff
>
> Property changes on: .
> ___________________________________________________________________
> Modified: svnmerge-integrated
> - /branches/v0_91_maint:1-5294
> + /branches/v0_91_maint:1-5299

I'm confused by this. Did you do:

  svn -R revert .

from the root of the tree? That should back out that property change.

> Can I please just manually merge my changes in from the branch, without
> svnmerge.py? I really don't have time today to mess around with this.

I can do the merge for you.

[mdroe@...603... matplotlib]$ svn update
U lib/matplotlib/ticker.py
U CHANGELOG
Updated to revision 5299.
[mdroe@...603... matplotlib]$ svnmerge merge
U CHANGELOG
C lib/matplotlib/texmanager.py
C lib/matplotlib/backends/backend_svg.py

property 'svnmerge-integrated' set on '.'

# We don't want to merge backend_svg.py -- we just want what's currently
on the trunk
[mdroe@...603... matplotlib]$ cp
lib/matplotlib/backends/backend_svg.py.working
lib/matplotlib/backends/backend_svg.py

# Manually resolve texmanager.py
[mdroe@...603... matplotlib]$ emacs -nw lib/matplotlib/texmanager.py

# Mark everything as resolved
[mdroe@...603... matplotlib]$ svn -R resolved .
Resolved conflicted state of 'lib/matplotlib/backends/backend_svg.py'

# Commit
[mdroe@...603... matplotlib]$ svn commit -F svnmerge-commit-message.txt
Sending .
Sending CHANGELOG
Sending lib/matplotlib/texmanager.py
Transmitting file data ..
Committed revision 5300.
[mdroe@...603... matplotlib]$

Cheers,
Mike

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
Darren S. Dale, Ph.D.
Staff Scientist
Cornell High Energy Synchrotron Source
Cornell University
275 Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853

darren.dale@...143...
office: (607) 255-3819
fax: (607) 255-9001
http://www.chess.cornell.edu

John Hunter wrote:

···

On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <mdroe@...31...> wrote:

So, this is more the fault of operating procedure (choosing not to do the
numpy renaming on the branch, for instance, which in itself was not a bad
decision in isolation), than the tool itself. Note that svnmerge did do the
right thing in your merge on about five diffs, and only two couldn't be
automatically merged. In my own experience, merges work far more often than
not, but as the trunk drifts further away from the branch, no doubt that
percentage will go down...
    
My (limited) experience has been same -- merges usually ""just work".
Part of the drift (eg the npy, np differences) we are currently
dealing with is explained by me doing things the wrong way for a
while, before I go. As more of us work to keep the branch in sync
where feasible, these kinds of problems should be less frequent.

I didn't mean to imply that doing the rename only on the trunk was necessarily a bad thing. It's a balancing act: too many changes to the branch runs the risk of introducing bugs, not enough changes can mean drift. It's like all the rivers in China: dammed either way.

Cheers,
Mike

On my machine I do need to manually purge these -- svn commit will
fail with a message like

    johnh@...539...:mpl> svn commit -F svnmerge-commit-message.txt
    svn: Commit failed (details follow):
    svn: Aborting commit:
'/home/titan/johnh/python/svn/matplotlib.trunk/matplotlib/lib/matplotlib/image.py'
remains in conflict

even if I have manually edited out all the conflicts. I then need to do

    johnh@...539...:mpl> rm lib/matplotlib/image.py.*

Maybe one of your emacs modes is helping you out behind the scenes?
Can you send me your emacs configs for svn?

JDH

···

On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <mdroe@...31...> wrote:

Minor point: On my machine at least, I don't have to manually clean up the
conflict files -- they are removed for me on the next commit. Those files
are really just for reference. If you use a SVN frontend for diffing (such
as psvn.el or meld) they are largely unnecessary.

John Hunter wrote:

Minor point: On my machine at least, I don't have to manually clean up the
conflict files -- they are removed for me on the next commit. Those files
are really just for reference. If you use a SVN frontend for diffing (such
as psvn.el or meld) they are largely unnecessary.
    
On my machine I do need to manually purge these -- svn commit will
fail with a message like

    johnh@...539...:mpl> svn commit -F svnmerge-commit-message.txt
    svn: Commit failed (details follow):
    svn: Aborting commit:
'/home/titan/johnh/python/svn/matplotlib.trunk/matplotlib/lib/matplotlib/image.py'
remains in conflict

even if I have manually edited out all the conflicts.

Oh -- it appears that "svn resolved" is what does this, not "svn commit". I didn't realise that just deleting the files was enough and have always used "svn resolved" as a matter of course. The convenient thing about "svn resolved" is you can do "svn -R resolved ." to resolve the whole tree once you're sure you're done.

I then need to do

    johnh@...539...:mpl> rm lib/matplotlib/image.py.*

Maybe one of your emacs modes is helping you out behind the scenes?
Can you send me your emacs configs for svn?
  
I use psvn.el, which is far easier to use IMHO than the built-in pcl-svn. You can get it here -- I haven't set any customizations on it.

http://www.xsteve.at/prg/vc_svn/

My favorite feature is the integration with ediff -- press 'E' in the svn-status buffer and it brings up an ediff session between your working copy and the SVN revision it came from.

Cheers,
Mike

···

On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <mdroe@...31...> wrote:

Michael Droettboom wrote:

John Hunter wrote:
  

Minor point: On my machine at least, I don't have to manually clean up the
conflict files -- they are removed for me on the next commit. Those files
are really just for reference. If you use a SVN frontend for diffing (such
as psvn.el or meld) they are largely unnecessary.
    

On my machine I do need to manually purge these -- svn commit will
fail with a message like

    johnh@...539...:mpl> svn commit -F svnmerge-commit-message.txt
    svn: Commit failed (details follow):
    svn: Aborting commit:
'/home/titan/johnh/python/svn/matplotlib.trunk/matplotlib/lib/matplotlib/image.py'
remains in conflict

even if I have manually edited out all the conflicts.
    

Oh -- it appears that "svn resolved" is what does this, not "svn commit". I didn't realise that just deleting the files was enough and have always used "svn resolved" as a matter of course. The convenient thing about "svn resolved" is you can do "svn -R resolved ." to resolve the whole tree once you're sure you're done.
  

I then need to do

    johnh@...539...:mpl> rm lib/matplotlib/image.py.*

Maybe one of your emacs modes is helping you out behind the scenes?
Can you send me your emacs configs for svn?
  
I use psvn.el, which is far easier to use IMHO than the built-in pcl-svn. You can get it here -- I haven't set any customizations on it.
  

I lied. There is one keyboard mapping I added that I've found pretty useful:

(global-set-key (kbd "s-s") 'svn-status-switch-to-status-buffer)
(define-key svn-status-mode-map (kbd "s-s") 'svn-status-bury-buffer)

This lets me toggle between the file I'm editing and the svn-status buffer using "Super-s" (Windows key-s). Makes it very convenient to edit a file, check the differences against the repository, and check them in.

Cheers,
Mike

···

On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <mdroe@...31...> wrote:

Darren Dale wrote:
> I'm sorry, I just don't understand how to use this.

And I'm also sorry for my mild panic attack yesterday. I had way too many
things coming at me all at once. Things are back to normal today.

I can do the merge for you.

[mdroe@...603... matplotlib]$ svn update
U lib/matplotlib/ticker.py
U CHANGELOG
Updated to revision 5299.
[mdroe@...603... matplotlib]$ svnmerge merge
U CHANGELOG
C lib/matplotlib/texmanager.py
C lib/matplotlib/backends/backend_svg.py

property 'svnmerge-integrated' set on '.'

# We don't want to merge backend_svg.py -- we just want what's currently
on the trunk
[mdroe@...603... matplotlib]$ cp
lib/matplotlib/backends/backend_svg.py.working
lib/matplotlib/backends/backend_svg.py

# Manually resolve texmanager.py
[mdroe@...603... matplotlib]$ emacs -nw lib/matplotlib/texmanager.py

# Mark everything as resolved
[mdroe@...603... matplotlib]$ svn -R resolved .
Resolved conflicted state of 'lib/matplotlib/backends/backend_svg.py'

# Commit
[mdroe@...603... matplotlib]$ svn commit -F svnmerge-commit-message.txt
Sending .
Sending CHANGELOG
Sending lib/matplotlib/texmanager.py
Transmitting file data ..
Committed revision 5300.
[mdroe@...603... matplotlib]$

Thanks for posting this. I'll take a sweep through the bug tracker this
weekend, and see if I can do this myself. I'll be working on documentation
this weekend, I'll add a section on merging to the documentation once I can
do it on my own.

Darren

···

On Thursday 29 May 2008 10:59:40 am Michael Droettboom wrote:

Darren Dale wrote:

  

Darren Dale wrote:
    

I'm sorry, I just don't understand how to use this.
      
And I'm also sorry for my mild panic attack yesterday. I had way too many things coming at me all at once. Things are back to normal today.
  

I know I've been there, and I completely understand. Sorry I was trying to "teach to fish" rather than just "giving you a bloody fish, already" in the midst of that... :wink:

  

I can do the merge for you.

[mdroe@...603... matplotlib]$ svn update
U lib/matplotlib/ticker.py
U CHANGELOG
Updated to revision 5299.
[mdroe@...603... matplotlib]$ svnmerge merge
U CHANGELOG
C lib/matplotlib/texmanager.py
C lib/matplotlib/backends/backend_svg.py

property 'svnmerge-integrated' set on '.'

# We don't want to merge backend_svg.py -- we just want what's currently
on the trunk
[mdroe@...603... matplotlib]$ cp
lib/matplotlib/backends/backend_svg.py.working
lib/matplotlib/backends/backend_svg.py

# Manually resolve texmanager.py
[mdroe@...603... matplotlib]$ emacs -nw lib/matplotlib/texmanager.py

# Mark everything as resolved
[mdroe@...603... matplotlib]$ svn -R resolved .
Resolved conflicted state of 'lib/matplotlib/backends/backend_svg.py'

# Commit
[mdroe@...603... matplotlib]$ svn commit -F svnmerge-commit-message.txt
Sending .
Sending CHANGELOG
Sending lib/matplotlib/texmanager.py
Transmitting file data ..
Committed revision 5300.
[mdroe@...603... matplotlib]$
    
Thanks for posting this. I'll take a sweep through the bug tracker this weekend, and see if I can do this myself. I'll be working on documentation this weekend, I'll add a section on merging to the documentation once I can do it on my own.
  

There is a little blurb on merging already in the coding guidelines, but it would be great to have it expanded by someone while it's still a fresh experience.

FYI: I have a little time today to do some documentation work myself today. I've been doing some minor edits (mostly formatting things) on the developer docs, and then was going to hit up the user docs. Does that step on your toes / duplicate effort? Anywhere where you think I would be more useful?

Mike

···

On Thursday 29 May 2008 10:59:40 am Michael Droettboom wrote:

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Three areas that you are the residing expert on are fonts, mathtext
and transformations, so user's guide chapters on these would be great.

In addition, one place where we can all make small, frequent
contributions is in the new faq section. Much of the stuff on the web
is out of date. When we answer questions on the mailing list that
recur, with 5 minutes of extra work, could put an entry in the FAQ
(user interface specific stuff, font stuff, install problems, seg
faults, web app server...).

···

On Fri, May 30, 2008 at 9:12 AM, Michael Droettboom <mdroe@...31...> wrote:

FYI: I have a little time today to do some documentation work myself today.
I've been doing some minor edits (mostly formatting things) on the
developer docs, and then was going to hit up the user docs. Does that step
on your toes / duplicate effort? Anywhere where you think I would be more
useful?

> FYI: I have a little time today to do some documentation work myself
> today. I've been doing some minor edits (mostly formatting things) on the
> developer docs, and then was going to hit up the user docs. Does that
> step on your toes / duplicate effort? Anywhere where you think I would
> be more useful?

I am planning on converting docstrings this weekend. We should keep everyone
posted of what we are working on though, with so much to do, it would be a
shame to duplicate effort.

Perhaps we should temporarily copy the users guide and htdocs into the doc
directory on the trunk. When someone is working on converting a section in
the users guide or an html file, he can add his name to the top of the file,
and then delete the file when done. That way we slowly delete the old docs
and can be sure we converted everything.

Three areas that you are the residing expert on are fonts, mathtext
and transformations, so user's guide chapters on these would be great.

In addition, one place where we can all make small, frequent
contributions is in the new faq section. Much of the stuff on the web
is out of date. When we answer questions on the mailing list that
recur, with 5 minutes of extra work, could put an entry in the FAQ
(user interface specific stuff, font stuff, install problems, seg
faults, web app server...).

Sounds good.

···

On Friday 30 May 2008 10:51:50 am John Hunter wrote:

On Fri, May 30, 2008 at 9:12 AM, Michael Droettboom <mdroe@...31...> wrote: