On Wed, May 18, 2011 at 2:55 AM, Daniel Shahaf <d...@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/