On Mon, Apr 16, 2001 at 03:50:07PM -0500, Karl Fogel wrote:
> 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.
Right. mod_dav_svn enforces this right now.
Once we can mark deletes in the client, then I'll relax the server.
>...
> 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?
Yup.
> 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.)
The server will tell the client about the change. We need to alter that, or
have the client filter them out.
I'm in favor of the latter. To the client, it will see a notification
"outside of the commit target scope" and can safely ignore it.
[ the scope is not passed to the server; it commits/reports on a whole-
repository basis. ]
So... you raise an entirely valid consideration (for when we mark deletes).
But I will still be able to keep the nifty dir_delta algorithm over on the
server :-)
[ for those readers who haven't been carefully code reviewing, you may have
missed a key point: mod_dav_svn (nor libsvn_ra_dav) keeps a list of all
the files/dirs that are involved in a commit. the changes just flow to the
server, it makes them in the transaction, and then commits it. for the
bumping process, I "create" the list by comparing the committed revision
against the previous revision using dir_delta. serializing that over the
wire gives me the list of changed items. effectively, the memory usage can
be O(depth) rather than O(num-changed). commit a million files? sure!! ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:28 2006