> 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_at_subversion.tigris.org].
Received on 2009-06-17 18:00:33 CEST