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
Received on 2009-06-17 19:01:23 CEST