Greg Stein, the situation described below may, unless I'm smoking the
Kool-Aid, affect the correctness of some code you're writing.
In the meeting in the CollabNet offices, we came up with a way to do
commits of adds and deletes without the parent being up to date.
Suppose that directory A is at revision 6, and the repository is at
revision 8, and you do this:
$ cd A/
$ svn delete foo.c
$ svn commit "Deleted foo.c because obsolete."
After this, the repository will be at revision 9, and in revision 9,
directory A does not have foo.c.
We had previously asserted that this situation would not be allowed --
that A/ would have to be up-to-date before you could commit the
deletion of A/foo.c. But in the meeting, we found a theoretically
sound way to handle the out-of-date case: leave an entry for foo.c in
A/SVN/entries. A will be at 6, the entry for foo.c will be at
revision 9, and A/SVN/text-base/foo.c will be absent. This indicates
that foo.c has been deleted, and that the deletion was committed in
revision 9. If A/ is ever updated to rev 9 or beyond, the entry for
foo.c would simply be removed at taht point. We'll probably have a
"deleted" flag on the entry so it's not necessary to check text-base
to discover it's been deleted, but anyway you get the idea.
Adds are handled symmetrically.
(Fitz, the All-Seeing Eye of the Developer Meeting, recorded all this
in notes/alpha_checklist, section V(B)).
Now, why does this matter to Greg Stein?
Greg, when you figure out whose revisions need to get bumped after a
commit, you bump directories if they've had a propchange, an add, or a
delete in them, right? But now, if adds and deletes can be committed
without the parent directory being up-to-date, your rule is going to
bump directories to the new revision when they shouldn't be bumped.
(Or maybe I'm just misunderstanding your algorithm, in which case run
netslap on me.)
-Karl
Greg Hudson <ghudson@mit.edu> wrote:
> Sometimes I lie awake at night wondering if we really know how to
> version directory contents given a CVS-like working directory. Here
> is one of the problem scenarios I came up with.
>
> In the last phone conversation I was a part of, we determined (or so I
> recall) that if a directory is listed in the WC as having version N,
> then it has the base properties of version N and all the entries of
> version N (plus any locally added entries), though those entries may
> have versions other than N.
>
> 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 pretty
> much has to be 5; updating it would require bringing in any entry
> changes from the new version, which could be expansive. 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.
>
> 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.
>
> 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?
And Jim Blandy <jimb@redhat.com> wrote, toward the end of the thread:
> From: Jim Blandy <jimb@zwingli.cygnus.com>
> Subject: Re: Directory versions in the wc
> To: Greg Hudson <ghudson@MIT.EDU>
> Cc: Greg Stein <gstein@lyra.org>, dev@subversion.tigris.org
> Date: 04 Apr 2001 17:00:49 -0500
>
> The first problem you mentioned --- how the effect of a commit that
> includes deletions should be reflected in the WC --- is something I
> hadn't thought of. I don't know the WC design well enough to comment;
> perhaps the folks who have done more there can explain.
>
> The filesystem does work as you say, but Greg S's DAV module is doing
> its own conflict detection. He may be rejecting cases the filesystem
> wouldn't. Is that a bug?
>
> We're meeting in person again tomorrow; perhaps we can get this
> straightened out then.
>
> The `svn cp dir1 dir2' case, I'm pretty sure we do handle correctly.
> `svn cp' will indeed do a real copy of the source dir on your local
> disk, but retains information about where it came from that allows us
> to call edit_fns->add_directory with the appropriate copyfrom_*
> arguments. Only local changes to the new tree will be transmitted.
> At the FS interface, it should turn into a call to svn_fs_copy,
> followed by calls to apply the local modifications.
Received on Sat Oct 21 14:36:28 2006