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

Re: prop ops on schedule-delete

From: <kfogel_at_collab.net>
Date: 2006-03-15 15:36:03 CET

Julian Foad <julianfoad@btopenworld.com> writes:
> kfogel@collab.net wrote:
> > "Ed Price" <ed.price@gmail.com> writes:
> >
> >>So you think they should be inconsistent but in the opposite way they
> >>are inconsistent now. Interesting :) Actually, I can see where you're
> >>coming from, I think... There is no value is changing the properties
> >>of a to-be-deleted file (AFAICS) but there *is* value in querying
> >>properties it had prior to deletion.
> > Exactly.
> >
> >>Hmm. I think you've changed my mind. I would now propose:
> >>
> >> * propget and proplist should Just Work on schedule-delete
> >>
> >> * propset and propedit should return a warning that the file is
> >> scheduled for deletion.
> > What about --force to override?
> 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
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 :-).

Also, if the working file was in a modified state at deletion time,
then it remains present on disk. Should the analogous thing happen
with properties?

> 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.


www.collab.net  <>  CollabNet  |  Distributed Development On Demand
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 15 17:27:14 2006

This is an archived mail posted to the Subversion Dev mailing list.