[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: Neels J Hofmeyr <neels_at_elego.de>
Date: Tue, 23 Aug 2011 15:49:34 +0200

On 08/23/2011 03:04 AM, Hyrum K Wright wrote:
> On Mon, Aug 22, 2011 at 7:18 PM, Greg Stein <gstein_at_gmail.com> wrote:
>> I'd give that a +1 if two things are implemented:
>>
>> 1) adjust the log message to note the hold-back 2) status shows 'H'
>> for held files that also have local mods

Ok, cool.

>> btw, regarding 'svn diff' showing changes to held files: I think it
>> should.
> +1 'svn diff' should still show mods to held files.

humph, ok, if you say so. I'd add a --do-hold option to diff then.

> 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.

So far, I had the impression that implementing it this way simply *is* all
things to all people. What differences in behavior would you separate?

> 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.

That's a really good point. Though we technically *could* simply stop
heeding certain props in a future version. Just the name is taken forever,
right? I don't think we're taking that much of a risk with svn:hold; but:

The part I'm most conservative about is how it affects merge.

 svn ps svn:hold foo
 [...]
 svn merge ^/trunk
  U foo
  U bar
 svn st
  HH foo
  M bar
 svn ci -mm
  Sending bar.....
 svn st
  HH foo

If someone did not 'svn status', they'd be annoyed to see 'foo' missing from
the commit of the merge. According to you, 'svn diff' also shows the merge
mods on 'foo', but they don't get committed. "huh, what?"

This is a situation mergers could whine about. All of a sudden they have to
take care about files someone else chose to put on hold globally, and why
did project management allow that anyway.

But I've talked about solutions, like project management deciding not to
allow this by means of a pre-commit, and this one:

 svn ps svn:hold foo
  [...]
 svn merge ^/trunk
  U foo
  U bar
 svn pl -v foo
  Properties on 'foo':
    svn:hold
      *
    svn:hold-merged
      *
 svn ci -mm
  svn: You have merged held-back files (see status output).
  svn: Please supply either --do-not-hold or --do-hold, explicitly.
 svn ci --do-not-hold
  Sending foo.....
  Sending bar.....
 svn pl -v foo
  Properties on 'foo':
   svn:hold
     *

Do you think we're likely to regret having created (letting neels create)
this kind of situation? That's the part I'm most unsure about. All the rest
seems to be lesser peanuts to me.

~Neels

Received on 2011-08-23 15:50:12 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.