On Wed, May 18, 2011 at 9:59 AM, Mark Phippard <markphip_at_gmail.com> wrote:
> 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
In case what Mark is referring to isn't clear: In 1.7 if our merge
target has pre-existing subtree mergeinfo, we no longer
unconditionally record mergeinfo on each of these subtrees to describe
a merge. Only subtrees which are touched by the merge are updated.
> 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.
> Mark Phippard
Received on 2011-05-18 16:40:52 CEST