Paul Burba wrote on Wed, May 18, 2011 at 09:51:17 -0400:
> On Wed, May 18, 2011 at 5:41 AM, Hyrum K Wright <hyrum_at_hyrumwright.org> wrote:
> > On Wed, May 18, 2011 at 9:32 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
> >> It would completely break mergetracking for about a dozen reasons :(
> >> I'll answer more detailed later, but this would just remove the
> >> property everywhere.
> >> And if you could hide it in a better way while still storing it in the
> >> wc, you would always forget to commit your mergeinfo only changes.
> >> Bert Huijben (Cell phone) From: Daniel Shahaf
> >> Sent: woensdag 18 mei 2011 8:55
> >> To: dev_at_subversion.apache.org
> >> Subject: [random line of thought] Hiding svn:mergeinfo
> >> 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?
> Hi Daniel,
> I'm not sure of all the implications of doing this are, but quick look
> reveals that this would either
> 1) (As Bert says) Break things, e.g. commit, diff
> 2) Do nothing. Mergeinfo would still be dealt with normally, e.g. svn
> merge, pl, pg, st
> In fact I was hard pressed to find a *useful* outcome from this
> (though I confess it was a brief look).
What I had in mind originally was making them non-user-visible, eg as
per the branches you mention later in your email.
[I'm not sure whether making them invisible is a good idea, I just
wonder if this is a good way to implement it.]
> >> [I suspect it might, but want to hear others' thoughts before laying
> >> out my own.]
> > I don't think hiding it completely is the way to go, but there has
> > been some half-implemented code to filter propchanges from various
> > operations. Completing this, and enabling it by default on selected
> > commands may scratch the same itch.
> I assume Hyrum is speaking of:
Received on 2011-05-18 16:11:49 CEST