[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [BUG] Borked 1.5.x CHANGES merging

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Sat, 12 Apr 2008 09:27:40 -0500

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.

> The merge tracking feature itself is doing the right thing. Why
> didn't you just merge the whole branch though? The change to the
> release notes would have just been skipped or worst case you could
> have reverted something.

I didn't merge the whole branch, because I only wanted the modifications
to CHANGES, not to the whole branch. Whether or not that was the right
decision can be debated, but, hey, it's version control: we can
always grab the other parts of r30112 later if we need them.

-Hyrum

Received on 2008-04-12 16:27:57 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.