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

Re: "svn copy -rHEAD" copies the wrong version.

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2003-10-01 01:57:29 CEST

Ben Collins-Sussman wrote:
> kfogel@collab.net writes:
>>Nice find! Have no idea what causes this, but agree it is an
>>egregious bug...
>>Julian Foad <julianfoad@btopenworld.com> writes:
>>>does not contact the repository to determine "-rHEAD". Instead it copies the version that currently exists in the WC. The following script demonstrates it.
> I think this is how we always meant/designed 'svn cp WC WC' to behave:
> it copies a chunk of WC to somewhere else in the WC, and schedules it
> all for addition with history. IIRC, 'svn cp WC WC' is not supposed
> to take a --revision argument at *all*.

I can see how that would have been an acceptable design, but in fact the "--revision" argument is mostly supported. It is only "-rHEAD" that fails; if I intead give "-r2" when the head revision is 2, it works.

The doc. string for svn_client_copy says that the "revision" argument is used if the source is a URL; this could be taken to imply that the revision is ignored if the patch is not a URL, but it is not explicit.

(The doc. string for svn_client_copy also says that a repository commit is performed if EITHER source or dest is a URL; surely this should be just if the destination is a URL.)

> To accomplish what you want above, we could simply tell people to use
> 'svn cp -rX URL WC', and then make 'svn cp WC WC' not accept
> --revision. I think that's a perfectly fine resolution.

It could be.

> Or, if you want to take a harder road, 'svn cp -rX WC WC' could simply be
> converted (quietly, under the hood) to 'svn cp -rX URL WC'.

This is what seems to be happening; just with a bug in it. Either that or some unintended functionality is operating and should be blocked.

I don't mind whether "-r" is allowed with a local path. Anyone want to choose?

- Julian

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 1 01:56:56 2003

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.