Antoine Pitrou wrote: > Nick Coghlan <ncoghlan <at> gmail.com> writes: >> Doing "svn resolved ." assumes that you did everything else correctly, >> and even then I don't see how svnmerge could both backport the py3k >> changes to the metadata and make its own changes and still get the >> metadata to a sane state. > > The metadata are discriminated by source merge URL. That is, the py3k metadata > are of the form "/python/trunk:<list of revisions>" while the release30-maint > metadata are of the form "/python/branches/py3k:<list of revisions>". (*) > I guess that's what allows svn to not shoot itself in the foot when merging.
Ah, thanks - that's the piece I was missing regarding why the svn resolved trick works (I have used that approach before and checked it as you did - as Martin has pointed out, the only time it definitely goes wrong is if you do an update *after* doing the local merge and the update included other backports). So I'll chalk the fact that svnmerge emits that false alarm up to a deficiency in the tool and only use the "regenerate the metadata" approach when I suspect I may have done the merge+update in the wrong order (since it's a harmless thing to do - it just wastes a couple of minutes relative to the svn resolved approach). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
