RetroSearch Browse

Sat Jan 31 01:43:36 CET 2009 · http://mail.python.org/pipermail/python-dev/2009-January/085755.html

> (I believe that svnmerge actually does get that case right, but I
> haven't checked it extensively - since if it does get it right, I don't
> understand why it leaves the conflict in place instead of automatically
> marking it as resolved).

I think this is a plain bug. It invokes "svn merge", which creates a
conflict, then removes the conflicted property (regardless of whether
there was a conflict), then writes the property fresh. It doesn't
consider the case that there might have been a conflict, just because
such conflict didn't occur in their testing.

> Regardless, the consequences of forgetting that you did the svn up after
> the merge instead of before (e.g. if it took some time to get the
> backported version working, or if something interrupted you between the
> initial backport/update and the final test and commit step) are fairly
> hard to clean up, so I prefer the safe approach (despite the extra
> minute or two it takes for svnmerge to recalculate the metadata changes).

If I find that it conflicts on commit, I rather restart all over.

Regards,
Martin

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2009-January/085755.html below:

[Python-Dev] [Python-checkins] Merging to the 3.0 maintenance branch