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

Re: Should propset on a schedule-delete target work?

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Mon, 08 Sep 2008 15:39:12 -0400

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:


(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


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

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.