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
On Sat, May 17, 2008 at 4:40 PM, John Hunter <jd...@gm...> 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
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 <jd...@gm...> 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 > Mat...@li... > 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
On Thu, May 29, 2008 at 9:01 AM, Darren Dale <dar...@co...> 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.
>
> $ 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
>
On Thursday 29 May 2008 10:04:34 am you wrote: > On Thu, May 29, 2008 at 9:01 AM, Darren Dale <dar...@co...> 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 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.)
Darren Dale wrote:
> On Thursday 29 May 2008 10:04:34 am you wrote:
>
>> On Thu, May 29, 2008 at 9:01 AM, Darren Dale <dar...@co...>
>>
> 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)
+=======
+ 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
On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <md...@st...> 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@flag: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@flag: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
John Hunter wrote: > On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <md...@st...> 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@flag: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@flag: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
Michael Droettboom wrote: > John Hunter wrote: > >> On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <md...@st...> 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@flag: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@flag: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 Thursday 29 May 2008 10:15:07 am John Hunter wrote: > On Thu, May 29, 2008 at 9:11 AM, Darren Dale <dar...@co...> 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 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
On Thu, May 29, 2008 at 9:41 AM, Darren Dale <dar...@co...> 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 I already screwed up everything once royally, so I'll let Michael comment on this.
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 <dar...@co...> >> > 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@wonkabar matplotlib]$ svn update U lib/matplotlib/ticker.py U CHANGELOG Updated to revision 5299. [mdroe@wonkabar 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@wonkabar matplotlib]$ cp lib/matplotlib/backends/backend_svg.py.working lib/matplotlib/backends/backend_svg.py # Manually resolve texmanager.py [mdroe@wonkabar matplotlib]$ emacs -nw lib/matplotlib/texmanager.py # Mark everything as resolved [mdroe@wonkabar matplotlib]$ svn -R resolved . Resolved conflicted state of 'lib/matplotlib/backends/backend_svg.py' # Commit [mdroe@wonkabar matplotlib]$ svn commit -F svnmerge-commit-message.txt Sending . Sending CHANGELOG Sending lib/matplotlib/texmanager.py Transmitting file data .. Committed revision 5300. [mdroe@wonkabar matplotlib]$ Cheers, Mike
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 <dar...@co...> > > > > 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@wonkabar matplotlib]$ svn update > U lib/matplotlib/ticker.py > U CHANGELOG > Updated to revision 5299. > [mdroe@wonkabar 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@wonkabar matplotlib]$ cp > lib/matplotlib/backends/backend_svg.py.working > lib/matplotlib/backends/backend_svg.py > > # Manually resolve texmanager.py > [mdroe@wonkabar matplotlib]$ emacs -nw lib/matplotlib/texmanager.py > > # Mark everything as resolved > [mdroe@wonkabar matplotlib]$ svn -R resolved . > Resolved conflicted state of 'lib/matplotlib/backends/backend_svg.py' > > # Commit > [mdroe@wonkabar matplotlib]$ svn commit -F svnmerge-commit-message.txt > Sending . > Sending CHANGELOG > Sending lib/matplotlib/texmanager.py > Transmitting file data .. > Committed revision 5300. > [mdroe@wonkabar 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 > Mat...@li... > 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 dar...@co... office: (607) 255-3819 fax: (607) 255-9001 http://www.chess.cornell.edu
On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <md...@st...> 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. JDH
John Hunter wrote: > On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <md...@st...> 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 Thursday 29 May 2008 10:59:40 am Michael Droettboom 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@wonkabar matplotlib]$ svn update > U lib/matplotlib/ticker.py > U CHANGELOG > Updated to revision 5299. > [mdroe@wonkabar 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@wonkabar matplotlib]$ cp > lib/matplotlib/backends/backend_svg.py.working > lib/matplotlib/backends/backend_svg.py > > # Manually resolve texmanager.py > [mdroe@wonkabar matplotlib]$ emacs -nw lib/matplotlib/texmanager.py > > # Mark everything as resolved > [mdroe@wonkabar matplotlib]$ svn -R resolved . > Resolved conflicted state of 'lib/matplotlib/backends/backend_svg.py' > > # Commit > [mdroe@wonkabar matplotlib]$ svn commit -F svnmerge-commit-message.txt > Sending . > Sending CHANGELOG > Sending lib/matplotlib/texmanager.py > Transmitting file data .. > Committed revision 5300. > [mdroe@wonkabar 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
Darren Dale wrote: > On Thursday 29 May 2008 10:59:40 am Michael Droettboom 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... ;) > >> I can do the merge for you. >> >> [mdroe@wonkabar matplotlib]$ svn update >> U lib/matplotlib/ticker.py >> U CHANGELOG >> Updated to revision 5299. >> [mdroe@wonkabar 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@wonkabar matplotlib]$ cp >> lib/matplotlib/backends/backend_svg.py.working >> lib/matplotlib/backends/backend_svg.py >> >> # Manually resolve texmanager.py >> [mdroe@wonkabar matplotlib]$ emacs -nw lib/matplotlib/texmanager.py >> >> # Mark everything as resolved >> [mdroe@wonkabar matplotlib]$ svn -R resolved . >> Resolved conflicted state of 'lib/matplotlib/backends/backend_svg.py' >> >> # Commit >> [mdroe@wonkabar matplotlib]$ svn commit -F svnmerge-commit-message.txt >> Sending . >> Sending CHANGELOG >> Sending lib/matplotlib/texmanager.py >> Transmitting file data .. >> Committed revision 5300. >> [mdroe@wonkabar 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 -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
On Fri, May 30, 2008 at 9:12 AM, Michael Droettboom <md...@st...> 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? 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 Friday 30 May 2008 10:51:50 am John Hunter wrote: > On Fri, May 30, 2008 at 9:12 AM, Michael Droettboom <md...@st...> 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? 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.