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 <[EMAIL PROTECTED]>
>>
> 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
-------------------------------------------------------------------------
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
