On Wed, May 18, 2011 at 2:55 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Mike remarked that svn:mergeinfo should never have been user-visible...
>
> So: what if we made svn_property_kind(NULL, SVN_PROP_MERGEINFO) return
> a value other than svn_prop_regular_kind, at least when both server and
> client were ≥1.7? Would that have any useful side-effects?
>
> [I suspect it might, but want to hear others' thoughts before laying out my own.]
I have said this before, but having thought about this a lot, I do not
agree with Mike's original remark. In the design of Subversion, I
think we had to make this user-visible. Otherwise, we are not letting
the user see the big picture.
For example, suppose we leave this in properties and just hide them
everywhere. This would be bad, because users could make mistakes in
how they commit and not have the property changes committed. We could
special-case this property and always commit it, even if the user does
a commit anchored lower in the tree. This would also be bad though.
Imagine you merge something into a WC and while you are working on
resolving conflicts you want to make some other change. Maybe you
have to fix a bug or a doc. Today, you can change an unrelated file
in your WC and commit it. But imagine if we saw the commit and
silently included the pending mergeinfo in the same commit?
I think many of these problems would exist in our design even if we
did not use the existing versioned properties to store the info. I
think we would need to introduce a lot of new concepts and
restrictions to support this feature in a way that was invisible. For
example, I think a WC would need to know when there was an uncommitted
merge in the WC and disallow any commit that did not include the
entire working copy. This might have been a good design change to
make, but it is probably too late.
I still think the best change is the one Paul made that will be in 1.7
and that is to be better about when we need to update subtree
mergeinfo. The next best change would be the ones Hyrum has in a
branch and that is to allow a user to choose to ignore those
properties in certain commands like diff and log.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-05-18 16:00:30 CEST