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

Greg Stein's several issues: proposed resolutions

From: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2000-12-21 22:17:04 CET

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,

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

   Question: Should we rejigger the editor interface to detect this

   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

   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

   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

   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. :-)

Received on Sat Oct 21 14:36:18 2006

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