You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Joe Drew <ho...@woot.net> on 2004/03/31 15:28:50 UTC
copy/remove weirdness
It seems I continue to be unable to send mail to
users@subversion.tigris.org. I'm sorry for forward this mail here, but I
think there are some bugs uncovered in it.
Re: copy/remove weirdness
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-03-31 at 11:20, Joe Drew wrote:
> Ok. So long as this is a known issue, I'm happy.
>
Definitely a known issue. :-)
> Here is how I would word such a note:
>
> NOTE: BASE, COMMITTED and PREV all refer to the working copy, and as such do
> not operate on repository URLs.
Ahhhh. Yes. Makes sense, thanks. Fitz: maybe we can add this to your
book TODO list?
>
> > Again, though: I will grant you that these two keywords *could* be
> > hitting the repository URLs as a means of converting the keywords into
> > real numbers. Perhaps we should file this as an enhancement request.
>
> I'd very much like a "try repository URLs when local resolution fails" RFE.
> I don't know what your long-term plans are for moving from .svn/entries, but
> that'd be a nice stopgap measure.
Want to file an enhancement request? Go for it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: copy/remove weirdness
Posted by Joe Drew <ho...@woot.net>.
Ben Collins-Sussman writes:
> On Wed, 2004-03-31 at 10:53, Joe Drew wrote:
>
>> Why shouldn't I be able to say "svn cp -r FOO file.c ."? Subversion should
>> know enough to look in the repository for this.
>
> Yes, I agree. In a perfect, world, this is about 1 of 27 ways in which
> the svn client could attempt to read the user's mind and be more
> friendly.
Hopefully one of several going-to-be-implemented ways. :)
> At the moment, however, the mere act of referring to a working-copy
> object is *exactly* equivalent to asking svn to look for the object in
> an .svn/entries/ file. But if the object is deleted, it's not in the
> entries file anymore. Until we change this implementation detail,
> however, deleted items must be resurrected by talking directly to the
> repository.
Ok. So long as this is a known issue, I'm happy.
>> > What's misleading here? You've asked for a path that doesn't exist in
>> > revision 4, and that's exactly what it told you.
>>
>> The misleading bit is that it acts differently from PREV/COMMITTED. There's
>> no indication in any documents that I've read (and, in fact,
>> PREV/COMMITTED's mention in the book seems to say the opposite) that it
>> relies on a working copy.
>>
>
> What's unclear in the book? I'd like to understand the source of
> confusion.
Right from the book:
HEAD The latest revision in the repository.
BASE The "pristine" revision of an item in a working copy.
COMMITTED The last revision in which an item changed before (or at) BASE.
PREV The revision just before the last revision in which an item changed.
(Technically, COMMITTED - 1).
BASE certainly refers to a working copy. The wording on COMMITTED and PREV
("item" in particular) implies to me, though, that it can equally well refer
to URLs or working copies. Now that I've re-read it, though, it is clear
that they transitively inherit BASE's reliance on a working copy. A note
specifically saying that, along with better error messages and/or an
implemented RFE below would be very welcome.
Here is how I would word such a note:
NOTE: BASE, COMMITTED and PREV all refer to the working copy, and as such do
not operate on repository URLs.
> Again, though: I will grant you that these two keywords *could* be
> hitting the repository URLs as a means of converting the keywords into
> real numbers. Perhaps we should file this as an enhancement request.
I'd very much like a "try repository URLs when local resolution fails" RFE.
I don't know what your long-term plans are for moving from .svn/entries, but
that'd be a nice stopgap measure.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: copy/remove weirdness
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-03-31 at 10:53, Joe Drew wrote:
> Why shouldn't I be able to say "svn cp -r FOO file.c ."? Subversion should
> know enough to look in the repository for this.
Yes, I agree. In a perfect, world, this is about 1 of 27 ways in which
the svn client could attempt to read the user's mind and be more
friendly.
At the moment, however, the mere act of referring to a working-copy
object is *exactly* equivalent to asking svn to look for the object in
an .svn/entries/ file. But if the object is deleted, it's not in the
entries file anymore. Until we change this implementation detail,
however, deleted items must be resurrected by talking directly to the
repository.
> > What's misleading here? You've asked for a path that doesn't exist in
> > revision 4, and that's exactly what it told you.
>
> The misleading bit is that it acts differently from PREV/COMMITTED. There's
> no indication in any documents that I've read (and, in fact,
> PREV/COMMITTED's mention in the book seems to say the opposite) that it
> relies on a working copy.
>
What's unclear in the book? I'd like to understand the source of
confusion. Yes, you're right, PREV and COMMITTED "rely on a working
copy". That is, the require a *working object* (i.e. something in an
.svn/entries file) in order to be converted into normal numbers. That's
why they don't work on URLs. Hopefully, that's what we've documented.
Again, though: I will grant you that these two keywords *could* be
hitting the repository URLs as a means of converting the keywords into
real numbers. Perhaps we should file this as an enhancement request.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: copy/remove weirdness
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-03-31 at 09:28, Joe Drew wrote:
> I can't seem to copy removed files without using a URL:
>
> $ svn rm a.txt
> D a.txt
> $ svn ci
> Deleting a.txt
>
> Committed revision 2.
> $ svn cp -r PREV a.txt a.txt
> svn: 'a.txt' is not under version control
Well, sure. The file is gone. You can't ask svn subcommands to
manipulate working-copy paths that aren't there. You'll need to look
through history (svn log) to find the last (rev,URL) coordinates in
which it existed, and then manipulate the URL if you want to resurrect
the file. The book (chapter 6) explicitly discusses resurrecting
deleted things.
> --- Separate issue ---
>
> Copying using some symbolic revision names gives me misleading error
> messages:
>
> $ svn cp -r PREV file:///home/hosehead/repo/a.txt .
> svn: A path under version control is needed for this operation
> $ svn cp -r COMMITTED file:///home/hosehead/repo/a.txt c.txt
> svn: A path under version control is needed for this operation
I agree, the error messages could be more specific. They should say
something like: 'The PREV/COMMITTED revision keywords only apply to
working copy paths, not URLs'.
> Using numeric values I get:
> $ svn cp -r 4 file:///home/hosehead/repo/a.txt c.txt
> svn: Path 'file:///home/hosehead/repo/a.txt' not found in revision '4'
What's misleading here? You've asked for a path that doesn't exist in
revision 4, and that's exactly what it told you.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org