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

RE: mergeinfo not eliding

From: Todd C. Gleason <tgleason_at_impac.com>
Date: Tue, 8 Sep 2009 10:56:39 -0700

> -----Original Message-----
> From: Mike Lenner [mailto:mike.lenner_at_gmail.com]
> Sent: Tuesday, September 08, 2009 9:21 AM
> To: users_at_subversion.tigris.org
> Subject: mergeinfo not eliding
>
> All -
>
> Hope someone can explain this behavior to me. So far, in reading the
> docs, I haven't been able to determine whether what I'm seeing is
> expected (and if so, why).
>
> Disclosure: I've done merges at places other than the root. I've done
> them at numerous levels of my repository. It seems this may not be a
> best practice, but I don't think it's invalid either.
>
> The situation I'm in now is this:
>
> $ svn pg svn:mergeinfo branches/a branches/a/src
> a - /trunk:8-10
> a/src - /trunk/src:8-10
>
> - Seems to me like this is redundant mergeinfo, no?
>
> - Am I in this situation because I've performed merges from places
> other than the root?

I see this same issue as well, including on areas where
files/directories have been renamed or moved. I get the idea that some
of it is due to the specific version of Subversion and may carry
forward, in that newer versions may not elide some of the unnecessary
mergeinfo created by older versions, and instead just keeps updating it.
At least, that's what's happening to us, and it's a pain because we get
a ton of paths marked as modified due to the subtree mergeinfo getting
modified, leading to various hacks being used at commit time.

As an example, it seems that if paths

/A/B/C/D
and
/A/B/C/E
have mergeinfo, and you merge at the level of
/A/B
and the merge operation says that only
/A/B/C/D/foo.txt
changed, for some reason when you go to commit, you see changes at
/A/B
/A/B/C/D
/A/B/C/D/foo.txt
/A/B/C/E
And the changes at those D and E directories are not the removal of
mergeinfo, but the updating of mergeinfo. The E directory didn't even
change in the merge operation, so I don't follow why its mergeinfo needs
to be updated.

We have a 1.5.2 server and have used client versions 1.5.2, 1.5.5, and
1.6.1. I don't know what if anything might automatically fix this or at
least help us, but it would be nice to see something. Looking at
http://svn.collab.net/repos/svn/tags/1.6.4/CHANGES , there are several
mergeinfo bugs marked as fixed, but nothing that strikes me as an
elision-related fix. And of the changes done, I don't know of an easy
way to tell which affect the server and which affect the client, so it's
hard to assess the urgency of upgrading our server.

Note that I've read articles such as

http://subversion.tigris.org/merge-tracking/func-spec.html

and

http://www.collab.net/community/subversion/articles/merge-info.html

which make it sound as though elision is done, though I don't see that
this is true. I've also seen scripts such as the one at

http://svn.haxx.se/dev/archive-2009-05/0438.shtml

but this isn't actually doing elision, it's just wiping out mergeinfo
(which is not what I want).

It may also help others here to know what version(s) you are running and
have run since 1.5.0.

--Todd

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2392589

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-08 20:00:09 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.