On Sat, Apr 12, 2008 at 10:27 AM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> Mark Phippard wrote:
>
> > On Sat, Apr 12, 2008 at 10:06 AM, Hyrum K. Wright
> > <hyrum_wright_at_mail.utexas.edu> wrote:
> >
> >
> > > In r30329, I merged r30112 from trunk which touched both CHANGES and
> the
> > > release
> > > notes. I didn't want to merge the release notes, because we no longer
> ship
> > > www/ (with the exception of hacking.html) with the release tarballs.
> So I
> > > cherry picked r30112 to CHANGES itself.
> > >
> > > If it annoys us to have CHANGES modified for every commit to 1.5.x,
> does
> > > that
> > > say something about how our users will feel?
> > >
> >
> > I do not think it really matters if it annoys us or it annoys our
> > users. It comes down to either you want to track that scenario or you
> > don't. In our case, for a release branch, I do not think we really
> > do. So we could just remove the mergeinfo it created or set it on the
> > parent folder and let it elide away.
> >
>
> I think it *does* matter if we annoy our users. Having a friendly user
> interface should be a design goal, and people will be reluctant to use
> Subversion if they are constantly being annoyed by it. Whether this
> particular instance matters much, I don't have too strong of feelings
> about.
>
> Another "annoyance" arises when there are several paths with explicit
> mergeinfo, and only one path which is affected by the merge. The
> signal-to-noise ratio of 'svn status' rapidly drops.
I am not trying to be flippant or cavalier when I say it doesn't
matter. I am simply saying that the choice to use properties was made
a long time ago and changes to properties are visible to the user.
That has good and bad aspects. Subversion's behavior here is correct
and fortunately it also gives the user the power to adjust it. Maybe
we will need to look for ways to make the latter aspect more apparent
in future releases, but I do not see any other way to do this. If you
merge a partial change into a branch we track that. If you as a user
know that what you merged is all that will ever be merged for that
revision, you can use --record-only and elide away the file-based
mergeinfo. Maybe this latter step is an area that can be approved
upon later. Perhaps in certain situations, the merge itself could
even be made to understand what you intended and avoid the situation?
I think a particularly area we are lacking now is understanding what
the right way to manually fix these situations is. Do you remove the
mergeinfo property? Do you do a --record-only merge and let elision
hopefully elide away the other mergeinfo? Something else?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-12 16:42:02 CEST