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

Re: Switch, DNS, repos roots, and busted working copies

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-12-07 11:23:19 CET

On Tue, 6 Dec 2005, Garrett Rooney wrote:

> On 12/6/05, Peter N. Lundblad <peter@famlundblad.se> wrote:
> This doesn't seem to occur over ra_local. Over ra_dav it does though.

Yeah, ra_dav doesn't ensure that this doesn't happen, but the other RA
layers does. I'm not sure how ra_dav knows where the FS path begins.

> > Was the WC in this state before starting to use 1.3.0, or does 1.3.0 allow
> > the WC to enter this state?
> The original person who found this problem here had it in an existing
> working copy, but with trunk you can also get into this situation via
> switch on a newly checked out working copy.
OK. We have two cases here:
- When we add the repos attribute, we don't check that it is a prefix of
the entries URL. This applies to old working copies.
- We allow switch to change the repository root.

The first problem is solved (in a patch in progress in my WC) by not
adding the repos attribute if it doesn't match the URL of the entry.

The second case is solved by disallowing that kind of switch operations in
libsvn_wc. I'm adding thesame error checking logic here that we have in
the non-DAV RA implementations. I don't think there is any reason to allow
this kind of inconsistency in a working copy. (There is an issue to make
switch behave like relocate if the repository root is changing, but that's
an enhancement.)

ON a side note, I'm adding a new error code. Hacking states that adding
new APIs restarts the soak. I hope a new error code doesn't count in this
case; that would be quite silly IMO.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 7 11:24:25 2005

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.