On Tue, Apr 03, 2001 at 02:45:06PM -0400, Greg Hudson wrote:
>...
> Okay. Now suppose someone does:
>
> svn co -r 5 dirname
> cd dirname
> svn rm -f alpha
> svn ci
> svn update -r 5 dirname
>
> After the "svn ci", what is the wc version of "dirname"?
It would be "current". Before a "svn ci ." can occur, the directory must be
up to date since you're removing an entry from the directory. So... if 5 is
"current", then the ci proceeds. If it isn't current, then the ci fails with
an "out of date."
> It pretty
> much has to be 5; updating it would require bringing in any entry
> changes from the new version, which could be expansive.
While true, we cannot remove a directory entry from a non-current version.
I could agree that this might not be ideal behavior, but it is entirely
possible that "alpha" doesn't exist in the latest, or it refers to an
entirely different subtree. We need to update "." to get the client up to
date with respect to the server.
> Does
> "dirname" still have an entry for alpha, with a distinguished revision
> number meaning "deleted"? If not, then the update back to rev 5 will
> fail, because the client won't report a variance for alpha and the
> server won't know to tell the client to bring alpha back.
Presuming the "up-to-dateness check" for "." that I mentioned above, then we
don't have the "deleted" state of the reverse-update problem.
> Perhaps I'm being paranoid, and we're already this clever. But I
> thought I would bring it up to set my mind at ease.
I think the issue is "solved", but perhaps not ideally. Needing to update to
the latest revision simply to toss a subdirectory is potentially expensive.
So... I'll offer an alternative solution to the problem:
Allow pruning (or simple omission) of subtrees in a checkout/update.
This would be along the lines of an update without CVS's "-d" switch. We
would probably need to leave markers in SVN/entries denoting "FOO exists,
but is not present in the WC." We have enough information during the
checkout/update to insert these entries.
We haven't talked (yet) about pruning or avoiding subdir creation. I would
think that we'd create subdirs by default, and the user would need to
explicitly prevent their creation. Either in total, or through some kind of
inclusion/exclusion globbing/regex.
> As a second and possibly harder issue, if I "svn cp dir1 dir2", what
> goes in the SVN files of dir2, which doesn't yet exist in the
> repository? If I commit immediately, how does the client figure out
> to report a single directory copy with no new files? What if I'm a
> putz and I cd somewhere into dir2 and try to commit there?
In the above scenario, what is the state of dir1 and dir2? Which are in the
repository, and which have not (yet) been comitted. From your continued
prose, it sounds like *both* dir1 and dir2 are brand new. I asked this
question once before regarding the fs_copy of a mutable node into a
transaction (which is what the above copy maps into). The answer was "the
second copy is an add". That is: the client will send dir1, dir2, and
dir2/dir1 all as "new" files to the server.
Committing from a subdirectory could do one of two things:
1) auto-commit up the tree until you reach an SVN tree
2) punt, and point the user up the tree
I'd say (2). I'd hate to see a "guess what I mean" behavior which just fires
by itself. I'd much rather see it explicit.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:27 2006