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

Re: SVN 1.5.1 creates svn:mergeinfo properties with svn-1.4 repo

From: Paul Burba <ptburba_at_gmail.com>
Date: Tue, 12 Aug 2008 14:32:17 -0400

On Wed, Aug 6, 2008 at 1:31 AM, Michael Reinelt <michael_at_reinelt.co.at> wrote:
> Hi all,
> from what I've been told, a subversion-1.5 client should not create the
> svn:mergeinfo property when used with a svn-1.4 repo.
> I got:
> lizard.trisoft.local:/MRK # svn --version
> svn, version 1.5.1 (r32289)
> compiled Jul 24 2008, 20:53:51
> lizard.trisoft.local:/MRK # cat /svnroot/MRK/format
> 5
> I hope that "format 5" is svn-1.4 repo...
> my subversion client creates the property when merging, and even when
> doing a "svn copy".

A 1.5 client should not *create* mergeinfo when merging from a pre 1.5
server, it may however propagate existing mergeinfo from the merge
source. For example, say you merged -r17 from 'trunk' to 'branch'.
If r17 added mergeinfo on trunk, then this mergeinfo would be added to
branch via the merge (just like any other property).

That said, you should definitely *not* see mergeinfo created on branch
that describes r17 from trunk. If you are seeing anything like that
(i.e. a merge of -rX creates mergeinfo on the target for rX)then that
is definitely a bug and not something that was intended for 1.5.

So if mergeinfo can't get created by a merge, how can it get into a
1.4 repository? Exactly as you pointed out, via svn copy,
specifically as WC to WC copy. As I'm sure you are aware, there are
four flavors of svn copy:

WC -> WC: copy and schedule for addition (with history)
WC -> URL: immediately commit a copy of WC to URL
URL -> WC: check out URL into WC, schedule for addition
URL -> URL: complete server-side copy; used to branch and tag

It looks like mergeinfo is being introduced into your repository via
WC to WC copies. Subversion (by convention) isn't allowed to contact
the server during WC to WC copies and thus doesn't know if the copy
destination would inherit* mergeinfo from some parent path that is not
present in the working copy (since the WC may not represent the
complete repository). This means that svn copy creates empty
mergeinfo (i.e. svn:mergeinfo with a "" value) on the copy destination
to prevent it from inheriting any mergeinfo.

* Keep in mind that the svn:mergeinfo property is inheritable, if a
path has explicit mergeinfo that is its mergeinfo, if it doesn't
(there is not svn:mergeinfo property set on the path) then the path
inherits the mergeinfo of it's nearest parent path with explicit

> I don't need merge tracking here, and the property makes some of my
> scripts which compare branches unusable, because 'svn diff --summarize'
> reports diffs due to the svn:mergeinfo property.
> How can I prevent svn from using the mergeinfo property?

In the long run the developer community needs to some or all of the following:

A) Make WC to WC copies not always produce mergeinfo.

B) Make commit smarter - don't commit svn:mergeinfo to pre 1.5
repositories ever (seriously, does anyone ever need this?)

C) Make commit even smarter - If a WC to WC copy produced empty
mergeinfo, check if the copy destination would inherit any mergeinfo
(if no explicit mergeinfo existed on it). If not, then the empty
mergeinfo is not necessary and can be reverted.

None of that helps you immediately though, so I would try the following:

If possible, use a REPOS to WC copy instead of a WC to WC copy. This
will not automatically create any empty mergeinfo on the copy
destination. Unfortunately if the working copy source has explicit or
inherited mergeinfo or the copy destination would inherit mergeinfo,
then mergeinfo will be present. In that case you can...

...Just delete the mergeinfo created by WC to WC copies before
committing them. This is crude but effective.


To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-12 20:32:43 CEST

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

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