Julian Foad <julianfoad_at_btopenworld.com> writes:
> On Sun, 2008-09-07 at 22:40 -0400, Karl Fogel wrote:
>> While working on issue #3282, I discovered that the propset below did
>> not error:
>>
>> $ svn rm some_versioned_file
>> $ svn propset pname pval some_versioned_file
>>
>> Instead, it just set 'pname' to 'pval' on 'some_versioned_file'.
>>
>> That seemed wrong! If a file is scheduled for delete, should we
>> really allow further data-adding operations on it, like propset?
>
> It's certainly wrong. I looked at this before (can't find any email I
> may have written about it though), and I think I found "svn"
> inconsistent: I think more than one of the property commands have this
> bug (pretending to read or write properties of a schedule-delete item)
> while the majority of commands correctly treat a schedule-delete state
> as a state that does not and cannot have properties at all.
Ed Price pointed out this catch-all issue to me:
http://subversion.tigris.org/issues/show_bug.cgi?id=2526
(I've linked to this thread from the issue now.)
>> Hmmm. There are a couple of different ways we could go from here:
>>
>> 1) I could tweak my patch to move the schedule-delete check up to
>> somewhere "higher" than libsvn_wc (maybe libsvn_client? I'm not
>> sure what entry point the mergeinfo code is using...)
>>
>> 2) We could ask ourselves whether setting new mergeinfo on a
>> schedule-delete target really makes sense. If it doesn't, we
>> could trap and clear the error, or maybe detect that the entry
>> is schedule-delete and not attempt to set the mergeinfo in the
>> first place.
>>
>> 3) Something I haven't thought of.
>>
>> I lean toward (2), but I'm not knowledgeable enough to be confident
>> that's the right way to go. Thoughts?
>
> Yes, (2). I'm confident that any attempt to read or manipulate a
> property on a schedule-delete item is an error, at both the WC and
> client levels, regardless of what the current implementation does.
Oy. Okay. I want to finish issue #3282 first -- it's a genuine
wc-corruption bug, and takes precedence. I'll try to look at #2526
afterwards, if no one beats me to it.
Thanks for the feedback, Julian
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-08 23:00:09 CEST