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

Re: Ben, question about adm_ops.c:svn_wc_revert

From: <cmpilato_at_collab.net>
Date: 2002-01-25 16:33:41 CET

Karl Fogel <kfogel@newton.ch.collab.net> writes:

> > This portion of code is exactly on the parent of the revert target,
> > which is a valid thing to do only if the revert target is not a WC
> > root. Why? Because by definition a WC root is either '.' (which you
> > really shouldn't be reverting while your inside of it) or a directory
> > that is disjoint with respect to its parent in the working copy,
> > meaning its parent has no entry for the target of the revert (and
> > therefore, we can't exactly update that non-existent entry).
>
> Uh. Ummm.
>
> I'm not seeing the connection between what you say above and the code
> in question, but it's probably easier just to talk about it when you
> get in.

Good Lord, I re-read that mush up there and don't really know what the
heck I was saying. Let me state it this way:

Revert needs to reset the state flags for the thing it is reverting
(removing any scheduling and conflict markers, etc.). For directories,
the state is kept in two places.

Let's say we are reverting A/D/G -- as 'svn revert A/D/G', not '(cd
A/D/G; svn revert)'. State for A/D/G is assumed to be stored in two
places:

(1) In A/D/G's entries file, as schedule= and conflicted= on the
    "svn:this_dir" entry.

(2) In A/D's entries file, as the same items on the entry for the "G".

Let's say that A/D/G turns out to be a wc_root. Since we aren't
querying for '.' (we passed 'A/D/G' to the check), we know that A/D
is NOT the rightful parent of A/D/G. Therefore, we know that we
should only revert the state of A/D/G in its own entries file (case 1
above), not in that of its presumed parent (case 2).

If, however, svn_wc_is_wc_root says that A/D/G is NOT a WC root, we
know that it is safe to revert A/D/G's state in both places.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:59 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.