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

commit logic.

From: Ben Collins-Sussman <sussman_at_newton.ch.collab.net>
Date: 2001-03-17 15:36:24 CET

I assume you all saw the bug that Fitz posted and Mike analyzed.

Namely, if your wc is at revision 1, *except* for `iota', which is at
revision 2, and then you try to commit a local mod on iota -- you get
an error.

Mike correctly analyzed the problem: the fs commit editor is
currently operating under the assumption that the commit is happening
on a single pristine tree. We haven't taught it how to deal with a
mixed-revision working copy yet. (We've been planning to. :))

But this is *exactly* the problem that Jim and I talked on the phone
about, and then I argued with Karl about. I still don't understand
the resolution to this problem. Jim and I came up with something, I
think, but then Karl pointed out that the problem isn't fixed.

We need to talk about this.


If I'm committing on transaction that is originally based on revision
1, and suddenly the client calls replace_file(baserev=2), what is the
proper behavior?

Ben's first instinct was: oh, in that case, replace_file should do an
fs_copy of the the immutable node 2:/path/to/iota into our transaction.

Jim's argument was: but how do we know that 2:/path/to/iota even
exists? Somebody may have renamed iota's parent dir in rev. 2!

Jim's solution was: punt on the problem, and instead declare that
replace_file() was called erroneously. New rule that editor-drivers
must follow: if you try to commit a target that it at a "unexpected"
rev, (i.e. a rev you wouldn't expect to find in a parent of a
different rev) then the driver must call delete(iota), and then
add_file(iota, copyfrom=2:/path/to/iota).

Karl's objection was: I don't see how this solves the problem. The
client *still* doesn't know that 2:/path/to/iota exists. Calling
{delete, add} has the exact same effect on the transaction as if
replace_file() had called {fs_copy}, and the same set of assumptions.

Ben's thought is: The user ended up with rev.2 of iota in one of two

    1. he committed iota, creating revision 2 in the fs.

    2. he did an `svn update iota'.

In case 1, we *know* that 2:/path/to/iota exists, so we're ok.

In case 2, we don't know that the path exists. BUT: I ask here --
if, when somebody else created revision 2, renamed one of iota's
parent dirs, wouldn't the update command fail in the first place?
Wouldn't the user get an error saying

   "sorry, I can't update iota for you. because I can't find
    /path/to/iota in the head revision. One of iota's parents is
    out-of-date; please update at a higher point in your working

Once again, we come back to the issue of how to do partial updates.
Ugh. :)
Received on Sat Oct 21 14:36:26 2006

This is an archived mail posted to the Subversion Dev mailing list.