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.)
Greg Hudson <firstname.lastname@example.org> 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 <email@example.com> wrote, toward the end of the thread:
> From: Jim Blandy <firstname.lastname@example.org>
> Subject: Re: Directory versions in the wc
> To: Greg Hudson <ghudson@MIT.EDU>
> Cc: Greg Stein <email@example.com>, firstname.lastname@example.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