Sticky svn:mergeinfo ?

[Emmanuel Blot <ma...@gmail.com>]

Hi,

I've been using SVN 1.5 (and fight against invalid svn:mergeinfo
properties for a while).
I'm now using SVN 1.6.2 (w/ a SVN 1.5.5 server).

However, it seems that some "sticky" svn:merginfo properties keep
being edited with no apparent reason when I merge unrelated changeset.
I'd really like to know whether it's a known bug, an expected (but
highly cumbersome) feature, or something I did understand the wrong
way ;-)

A common use case:

# A new branch is forked from the trunk.
svn cp ^/trunk ^/branches/newbranch

# Some directories are svn copied from another branch to the new branch
svn cp ^/branches/oldbranch/a ^/branches/newbranch/a
# The above command creates expected svn:mergeinfo on
"^/branches/newbranch/a" directory

# Now, a fully, unrelated changeset is merged into the newbranch
svn co ^/branches/newbranch/a
cd a
svn merge -c X ^/branches/devbranch
# where devbranch changeset [X] contains a single change from another directory
svn diff -c X ^/branches/devbranch
  b/file.c (revision X)

# After the merge, the unrelated branches/newbranch/a directory sees
its svn:mergeinfo property updated
# as follow
svn diff
Property changes on: a
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /branches/devbranch/a:r9097

# This leads to an unexpected status, as directory 'a' never get
updated with this merge command,
although it appears as "(propery)modified"

svn st
 M      .              # expected
M       b/file.c     # expected
 M      a             # unexpected

I don't see the point of updated 'a' svn:mergeinfo property here, as
  1. 'a' has not been modified, AND
  2. 'a' was not part of the merged changeset

After several rounds of merge commands, there are dozens of such
svn:mergeinfo alterations that get propagated from branch to branch,
which make svn st and svn diff quite difficult to read, as most of the
printed change entries are not related to actual developer changes.
Then developers start to get confused, and make errors.

Is there any way to get rid of this behaviour ?

Thanks in advance,
Manu

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

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: Sticky svn:mergeinfo ?

[Tyler Roscoe <ty...@cryptio.net>]

On Wed, Jun 17, 2009 at 05:58:54PM +0200, Emmanuel Blot wrote:
> The trouble is, for the end user, that something is does not even know
> about appears as 'modified', whereas it has not (except for the
> internal machinery of SVN).
> 
> Will this feature be hidden in a future SVN release (i.e.
> svn:mergeinfo changes that do not apply to the actual changes), or
> will it stay as is ?

I agree that this can be confusing for developers. I believe I've seen
some discussion about hiding the mergeinfo mechanics from the user, but
I don't know what the current thinking is in the svn dev community.

> What I don't understand/follow is why in this kind of use case, 'a' is
> marked as merged, whereas no actual merge occur: the directory has not
> been modified, and any attempt to merge a subset of the same changeset
> again will do a no-op, whether svn:mergeinfo do exist or not. At

I guess the short answer is "there are technical reasons / that's how it
was designed".

To avoid writing mergeinfo to 'a', svn would need to look at the
changeset you're merging in and decide that a is not modified by any of
the revisions in that changeset. This might become expensive. 

Plus, I could argue that the result is *more* confusing when looking at
the history of 'a' because there will be no record of all these "no-op"
changes having been merged in. Was that changeset merged to 'a' at all?
Was it excluded on purpose? What about a's siblings? At least with the
current system I can see that the changeset was applied to everyone,
whether it made changes to those files/dirs or not.

I'm not a subversion developer so I'm just speculating, fwiw.

hth,
tyler

Re: Sticky svn:mergeinfo ?

[Emmanuel Blot <ma...@gmail.com>]

> This has been discussed a lot lately. Check the archives.
Ok

>> # After the merge, the unrelated branches/newbranch/a directory sees
>> its svn:mergeinfo property updated
> Right, because something else has been merged and your subtree merge
> point branches/newbranch/a needs to know about that merge so that
> Subversion doesn't attempt to merge those changes again in the future.

The trouble is, for the end user, that something is does not even know
about appears as 'modified', whereas it has not (except for the
internal machinery of SVN).

Will this feature be hidden in a future SVN release (i.e.
svn:mergeinfo changes that do not apply to the actual changes), or
will it stay as is ?

I'm not sure to understand how a developer may be able to locate his
changes from the internal svn:mergeinfo changes after a couple of
merge: svn:mergeinfo appear from everywhere, which make the use of svn
st and svn diff hardly usable, as actual changes get mixed with dozens
or hundreds of "unrelated" svn:mergeinfo changes.

> But in this case, I think that mergeinfo is
> doing exactly what it's supposed to: remember which revisions have
> already been merged into which subtrees in your repo.

I'm not sure to understand this point (but I guess I should read the
archives first).
I want/need to keep svn:mergeinfo information, they are useful. I
really do need them.

What I don't understand/follow is why in this kind of use case, 'a' is
marked as merged, whereas no actual merge occur: the directory has not
been modified, and any attempt to merge a subset of the same changeset
again will do a no-op, whether svn:mergeinfo do exist or not. At
least, from a user perspective, which may be quite different from a
SVN developer perspective ;-)

Thanks for your answers,
Manu

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

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: Sticky svn:mergeinfo ?

[Tyler Roscoe <ty...@cryptio.net>]

On Wed, Jun 17, 2009 at 12:49:58PM +0200, Emmanuel Blot wrote:
> However, it seems that some "sticky" svn:merginfo properties keep
> being edited with no apparent reason when I merge unrelated changeset.
> I'd really like to know whether it's a known bug, an expected (but
> highly cumbersome) feature, or something I did understand the wrong
> way ;-)

This has been discussed a lot lately. Check the archives.

> # A new branch is forked from the trunk.
> svn cp ^/trunk ^/branches/newbranch
> 
> # Some directories are svn copied from another branch to the new branch
> svn cp ^/branches/oldbranch/a ^/branches/newbranch/a
> # The above command creates expected svn:mergeinfo on
> "^/branches/newbranch/a" directory

When you do this, you have performed a subtree merge with a consequent
creation of subtree mergeinfo. As you say, this is expected.

> # Now, a fully, unrelated changeset is merged into the newbranch
> svn co ^/branches/newbranch/a
> cd a
> svn merge -c X ^/branches/devbranch
> # where devbranch changeset [X] contains a single change from another directory
> svn diff -c X ^/branches/devbranch
>   b/file.c (revision X)
> 
> # After the merge, the unrelated branches/newbranch/a directory sees
> its svn:mergeinfo property updated

Right, because something else has been merged and your subtree merge
point branches/newbranch/a needs to know about that merge so that
Subversion doesn't attempt to merge those changes again in the future.

> After several rounds of merge commands, there are dozens of such
> svn:mergeinfo alterations that get propagated from branch to branch,
> which make svn st and svn diff quite difficult to read, as most of the
> printed change entries are not related to actual developer changes.
> Then developers start to get confused, and make errors.
> 
> Is there any way to get rid of this behaviour ?

If you are 100% confident that you don't need Subversion to keep track
of the mergeinfo on branches/newbranch/a, you can remove the
svn:mergeinfo property. But in this case, I think that mergeinfo is
doing exactly what it's supposed to: remember which revisions have
already been merged into which subtrees in your repo.

hth,
tyler