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