On Tue, Aug 23, 2011 at 8:49 AM, Neels J Hofmeyr <neels_at_elego.de> wrote:
> 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.
Are you saying diff would hide files by default, and then expose them
with the option, or vice versa? I'm in favor of the latter (do no
hiding by default).
-Hyrum
>
>
>
>> 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
>
>
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Received on 2011-08-23 15:56:41 CEST