kfogel@collab.net wrote:
> Julian Foad <julianfoad@btopenworld.com> writes:
>
>>You've got to be kidding.[*] No way. KISS. Don't even allow the
>>user to view the properties of a schedule-delete item, just like we
>>can't view or copy its main text. The user can specifically ask to
>>see the properties at -rBASE if that's what he/she wants.
>>
>>(A schedule-delete item should behave locally as if it were already
>>deleted. In fact, the main text IS already deleted, and the properties
>>should be too. They aren't restored by "revert", of course, so there's
>>no reason to keep them at all.)
>
> Can you clarify what you mean by "they aren't restored by 'revert', of
> course, so there's no reason to keep them at all"? The main text is
Sorry, I'd been experimenting and what I wrote partly referred to what I'd
discovered. I meant that "revert" copies the base properties over the working
versions, so it doesn't need this copy of the to-be-deleted working properties.
"svn delete" (which requires "--force" if there are any local text or
property mods), as well as deleting the working text, might as well delete the
working props, because they are of no further use after that point unless we
contrive a reason why they should be retained and accessible.
If we agree that the to-be-deleted working props shouldn't be accessible, then
there's no functional reason why the working props file should or shouldn't be
retained in the admin dir, it's only an implementation detail.
> restored by 'revert'... By the way, try this:
>
> $ svn delete some-versioned-file.txt
> $ svn st -q
> D some-versioned-file.txt
> $ svn cat some-versioned-file.txt
>
> You may be surprised by the results :-).
It displays the base version of the text, which (I think) is the version it's
designed to display, but, if it were consistent with other commands, it
wouldn't be able to locate the versioned object given only a reference to a
non-existent WC file. (And it is wrong to do so because if
"some-versioned-file" did exist on disk, it might be the new name of a
different object.)
In my interpretation of peg revisions, it is behaving as if there were an
implicit "@BASE" on the argument. I consider that a bug in "svn cat" because
it is undocumented and inconsistent with most commands.
> Also, if the working file was in a modified state at deletion time,
> then it remains present on disk.
Ah, this may be the crux: no it doesn't, not when I try it. Are you thinking
of the case when you "svn add" and then "svn delete --force" without ever
having committed? That's different.
> Should the analogous thing happen with properties?
Generally, yes, the behaviour should be analogous. We seem to have the concept
that
* local filesystem commands outside Subversion act on the text, and "svn cat";
* "svn prop*" act on properties;
* most "svn" commands (add, rm, cp, mv, revert, resolved, diff, merge, ...)
act on the object as a whole: text and properties together.
That seems good.
>>So:
>>
>>* All five prop commands should fail on schedule-delete targets.
>>
>>* The failure should probably be a warning rather than an error, in
>>line with our recent policy of warning about unversioned targets
>>rather than erroring out.
>>
>>- Julian
>>
>>[* I know you don't kid about stuff like this without a smiley, so
>>it's probably just that you were typing ahead without giving it your
>>cool and rational attention.]
>
> Well, I think this question is complex enough that there isn't one
> Obviously Right Answer, as you can see from my questions above.
Sorry if I was too presumptuous.
Are we converging?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 15 18:15:59 2006