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

Re: bring on your concerns about svn:hold, please

From: Hyrum K Wright <hyrum.wright_at_wandisco.com>
Date: Mon, 22 Aug 2011 20:04:02 -0500

On Mon, Aug 22, 2011 at 7:18 PM, Greg Stein <gstein_at_gmail.com> wrote:
> On Mon, Aug 22, 2011 at 19:19, Neels J Hofmeyr <neels_at_elego.de> wrote:
>> So if 'svn:hold' *only* affects commit; Would I eventually be allowed to
>> code this into trunk?

I think we don't need to be talking about a one-size-fits-all approach
here. While I don't think an explosion of special properties is good
either, a well chosen set which handle the various behaviors people
want may be a better solution than an 'svn:hold' attempting to be all
things to all people.

Another consideration is that properties live forever, possibly even
past some eventual 2.0, and when implementing new special props,
conservative is definitely the way to go. We can always add more; we
can't ever take them away.

> I'd give that a +1 if two things are implemented:
> 1) adjust the log message to note the hold-back

Are you talking about the suggested log message that appears in
$EDITOR, or munging the log message in flight? I'm fine with the
former, but the latter feels it's a huge minefield.

> 2) status shows 'H' for held files that also have local mods
>> And I can stay on the branch for a while to come, too. Would just be more
>> convenient on trunk, cuts out all that merging.
> I prefer trunk development. But only if you're talking about 'svn
> commit', the log message changes, and 'svn status'. Affecting other
> commands... then we get back into discussion :-)

By limiting the scope as I mention above, it's much easier to
implement on trunk.

> btw, regarding 'svn diff' showing changes to held files: I think it
> should. There are two types of changes to those held files:
> local-only, and changes that you *want* to propagate to your
> teammates. If you hide local mods, then a developer could miss the
> need to commit the important work.

+1 'svn diff' should still show mods to held files.

Feel free to introduce some option to diff which could potentially
screen files with this property, but as the default behavior, 'svn
diff' should show all mods to a working copy.


uberSVN: Apache Subversion Made Easy
Received on 2011-08-23 03:04:31 CEST

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