[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: HEADS UP: Damaged mergeinfo in our history; likely pain in our future.

From: Paul Burba <ptburba_at_gmail.com>
Date: Fri, 11 Dec 2009 17:38:49 -0500

On Thu, Dec 10, 2009 at 11:38 PM, Paul Burba <ptburba_at_gmail.com> wrote:

> I fixed svn_mergeinfo_parse(), svn_mergeinfo_to_string(),
> svn_mergeinfo__catalog_to_formatted_string(), and
> svn_mergeinfo__to_formatted_string(), so that any time we create
> svn_mergeinfo_t from a string or vice-versa, we tolerate relative
> paths in the input, but create absolute paths in the output.  This
> solves the original problem Mike saw with his sync merges...
>
>>>  Properties on '.':
>>>   svn:mergeinfo
>>>     /subversion/trunk:879653-880579
>>>     subversion/trunk:880580-880583
>>
>> FWIW, we already have this problem on our 1.6.x branch.
>
> ...but in cases like this branch, it actually makes things worse,
> because when the second "identical" key/val is parsed, it overwrites
> the first one, so we lose mergeinfo during merges and get partial
> (i.e. wrong) answers to svn mergeinfo queries.  We should be able to
> simply merge the results for identical keys (I'll look at that
> tomorrow).  Other than that I don't see any other problems, beyond
> what I already mentioned regarding svn_mergeinfo_diff (which isn't
> much of a problem).
>
> Paul

Fixed all the aforementioned problems (e.g. svn mergeinfo and svn
merge bustage) in r889840. Will nominate for backport later tonight.

Spent some time looking to see where else relative merge source path
mergeinfo might burn us. Fortunately things don't look that. One
obvious problem area, svn log -g, is unaffected, regardless of whether
your client or server has rr889840. The very short story here is
svn_fs__canonicalize_abspath() saves us from trouble.

The non-merge, non-mergeinfo problem areas are:

1) svnadmin load preserves relative-path mergeinfo.

2) If you are converting svnmerge.py properties to svn:mergeinfo with
svnsync and the svnmerge-integrated props being converted have
relative paths, these will be preserved.

3) svndumpfilter, like svnadmin load, preserves any relative pathed
mergeinfo in the dump stream.

4) Serving your repos via Apache or svnserve: Relative paths in URL
sources for copies/moves are preserved in the destination. Also, if
you are merging to a path without explicit mergeinfo and have to
contact the server for any inherited mergeinfo, if the latter has
relative paths, you get relative inherited paths and probably the
wrong merge.

All of these are fixed by rr889840. Note that 4 is fixed simply by
having a patched client.

Lastly I would again emphasize that you can only get relative source
path mergeinfo in two ways: First, if you use svnadmin load
--parent-dir with a relative path (issue #3547, fixed by Mike).
Second, if you manually use svn propset to create mergeinfo with
relative paths (which is no longer possible with rr889840).

Paul
Received on 2009-12-11 23:39:23 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.