[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 merge -c revision and svn diff/log confusion

From: Stein Somers <ssomers_at_opnet.com>
Date: Thu, 29 Oct 2009 19:50:13 +0100

As far as I get the question right, I have not seen many useful answers in 6
weeks. If the question is a FAQ, we have come at the point that the most
frequently posted reply is that it was answered before, without a reference
to the earlier answer, which then turns up in searches as answer, making it
even harder to find the truth.

If you have enough intellectual capacity, try to understand all of

My own mergeinfo for dummies like myself is:

Some svn versions near 1.5 write spurious svn:mergeinfo attributes with
an empty value. The empty value does have a meaning apparently, but it
happens when you don't intend to exploit that meaning. Some actions even copy
all revision properties of the working copy top folder to files, including
bugtraq and svn:ignore properties. Duh?

Anyway, when merging later, each svn:mergeinfo value grows - which makes
sense if the svn:mergeinfo were intended to be. Every commit grows. Worse,
every update of a working copy updates files: the svn:mergeinfo properties of
the file are updated, the file contents stay the same, but unfortunately the
last-modified timestamp is touched, so your build system assumes the file has

Luckily, since we are dummies and no hard core subverters, we only ever merge
complete working copies and commit them all at once. We don't fool around
with shallow checkouts or switched working copies. We have no
"non-inheritable mergeinfo ranges" (with an asterisk). So we can put this all
past us by simply deleting all svn:mergeinfo below the working copy top. In
an updated, unchanged working copy:

        svn propdel svn:mergeinfo -R
        svn revert . # undelete mergeinfo on the top folder
        svn commit -m "Removed stray mergeinfo"

After that you could try to avoid the empty svn:mergeinfo being committed
again, or even write a pre-commit hook to make sure. Or just do it again when

Once you upgrade to version 1.6 or so, you never need to fix matters like
this again.

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-29 19:51:12 CET

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