[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: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2006-03-15 18:46:40 CET

Julian Foad writes:
> kfogel@collab.net wrote:
> > Julian Foad <julianfoad@btopenworld.com> writes:
> >
> > $ 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.
>

I'd say it behaves as if there were an implicit -rBASE given, and
that's what happens, at least according to the general revision
resolution code. If the target was a working copy path, then the
default operative revision is BASE AFAICT. blame and ls behave the
same.

Thanks,
//Peter

---------------------------------------------------------------------
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:47:03 2006

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.