Greg, a few different threads discussed in one email here; I know
that's not ideal mailing list technique, but in this case it may help
keep things organized.
Ben made a list of the various issues you recently raised, and we went
over them at the whiteboard here, and then we talked with JimB.
(Would have done this all on the list except can't type that fast,
unfortunately.)
Here is the list, with our current head-state regarding each. The
items are pretty much unrelated. It happens that Ben, Jim, and I all
have pretty much the same head-state on these, which is why we're
presenting ourselves as the Three Musketeers here. :-)
1. Should property names be URIs?
(Oh, I see you just sent a mail saying "I relent, for now.". Heh.
Anyway, I'll describe this issue briefly so we all agree what we're
talking about.) The two sub-questions are:
a) Subversion-specific prop names need a unique prefix. Should
that prefix be "svn:" or some longer URI? We lobby for plain
old "svn:" -- it's easier to work with, and the namespace
protection is frankly about the same.
b) Should all other prop names always be URIs? When the user
doesn't specify a URI, should Subversion force it into a URI?
We say no, let the namespace sort itself out. This has worked
fine with many other systems in the past, and our experience
(which may or may not be the same as yours) suggests that URI
schemes don't really improve matters, they just make everyone
work with longer strings.
Were those the two questions you understood to exist, too, and
regarding which you relented ("for now")? :-)
2. Detecting revision-shift during an update.
Suppose you're running an update. The client first reports local
state, and then starts getting an appropriately-tuned tree delta
back from the server. But immediately after reporting local state,
a smaller, quicker update happens to some file that's also involved
in the larger update. Now the larger incoming tree delta will be
wrong.
Question: Should we rejigger the editor interface to detect this
case?
Answer: No, it can be handled entirely with client side bookkeeping
or locking, and should be thus handled. Adding new arguments would
result in only minimally more convenience in this one case, and
the arguments would be ignored baggage in most other cases.
(I'm not sure you were firmly advocating rejiggering the editor for
this, actually. Anyway, I just wanted to reassure you that the
client can detect this independently of the delta coming back from
the server, either by noticing whether the file has changed since
state was reported, or by not permitting it to change after state
gets reported until the update is done.)
3. The problem of copying or moving a file on top of another file.
How do you express the ancestry of both the thing being replaced,
and the thing that replaced it?
Ben said "You first do delete(), then add_file() or
add_directory()." Fine, but there's a corollary to this: the
directory in which all this is happening must be up-to-date,
because changes to file identity (as opposed to contents) are
changes to its parent directory. So the delete() will return an
out-of-date error if the dir's revision reveals out-of-dateness,
which is what we want.
However, this begs the question: then why does replace_file() even
have an ancestor_path argument? If we do copies and moves with a
combination of delete() and add(), then replace_file() is *only*
useful for text changes to a file.
We agree that this seems to be the case, and therefore that the
ancestor_path argument to replace_file() should go away. (There
may be analogous changes implied by this elsewhere in the editor; I
haven't studied that question yet but expect it to be obvious when
I do.)
4. Issue of how repository paths are stored in the working copy
metadata.
You're right -- the `repository' file is a holdover from CVS
thinking, and is not the appropriate way to do things here.
Instead, each entry can store this information; and by default
entries inherit the attribute from their directory (that is, the
entry whose name is SVN_ENTRIES_THIS_DIR). This will get us
repository mixing cleanly, except, of course, for writing the code
to do it. :-)
After all, the originating repository is really just part of the
ancestry information, which is already stored in the entries! It
only makes sense for additional ancestry information to hang off
them, too.
Anyway, the rest of this issue is technical and can be offlined
(I'd still like your opinions on it, but it's a relatively minor
implementation issue and doesn't need to be solved in this thread.)
5. ra interface:
You were saying "Why do we need those root_path arguments to the
vtable functions, when the root_path was already indicated in the
original URI to open_session()?"
We agree. They're gone, Ben removed them. However, there is a new
question: does the client side first discover the latest rev num
and then request it explicitly, or does it simply ask for the
"latest" and never actually say what rev num that is?
The latter way -- when you request a URI, you're actually
requesting the latest revision at that URI -- may be too simple.
The problem is, what about when someone wants to check out a
revision other than the latest? (This happens all the time, as I'm
sure you've experienced in using CVS.)
Don't have a definite proposal yet for this one, would like to know
what you think, but anyway we need to have a way to request
non-latest revs. Here's my initial thought on a solution:
open_session (URI, &TOK);
get_latest_revision (TOK) ==> some rev number
(Cached inside TOK so no extra
network turnaround is required.
It doesn't matter that it might
not be the true latest anymore.
Heck, that could happen even when
someone requests the latest
directly from the server -- in the
time it takes for the answer to
come back to the client, a new
latest might appear anyway! So we
shouldn't worry too much about
that.)
This latest rev number would be used during checkout(), say: the
client passes it to get_checkout_editor(), and the returned
editor/baton combination has that revision stored, and is therefore
able to set up all the working copy data correctly even though the
editor's driver might not ever pass a revision number to an editor
callback.
This is how checkouts are currently working, the only difference
being that the revision number is coming from a magic hat, since we
don't have get_latest_revision() yet.
6. The flux capacitor tops out at 88mph.
Yes, but why would you ever want to go faster than 88mph?
7. A small bug: subdir entries should not say their ancestry, because
that's recorded in subdir/SVN/entries.
Yes, I'm working on fixing that right now (or maybe I just did, I
can't remember).
Whew, there. Let us know what you think. Remember not to delete any
subthreads from your reply, even if you don't have anything to say
about them. :-)
-K
Received on Sat Oct 21 14:36:18 2006