On Wed, May 18, 2011 at 9:59 AM, Mark Phippard <markp...@gmail.com> wrote: > 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.
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. Paul > 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/
