On Thu, Dec 21, 2000 at 10:58:38AM -0500, Geoffrey M. Clemm wrote:
> From: Greg Stein <gstein@lyra.org>
>...
> That's very reasonable. I just would like to make sure that the baseline
> protocol will be suitable for Subversion when you're ready to use it.
Just did a quick read-thru. Sub-baselines wouldn't apply. BASELINE-CONTRL
would be a no-op. There would be a single baseline-selector and a single
baseline history per repository. There would be a baseline per
global-revision.
Note that I was going to have a resource that corresponded to each
global-revision already. That resource would hold our "per-revision"
properties.
> I'm also a bit unclear
> with the spec in terms of the new resource types: baselines, baseline
> selectors, baseline histories, and baseline-controlled collections. That is
> a fair bit extra :-)
[ just read the draft's baseline section a couple times now ]
> I believe these all correspond to information that is currently being
> stored by the Subversion server. I'm still coming up to speed on
> Subversion, but I believe the following is an accurate mapping:
>
> Subversion => DeltaV
>
> repository
> => baseline-controlled collection
> (repository) version
> => baseline
We use the term "(repository) revision", but the mapping holds.
> set of all (repository) versions
> => baseline history
> the thing that identifies what (repository) version is current
> => baseline selector
Yup. I don't think the selectory would really be used, though.
>...
> After spending some more time looking at this, I no longer think that
> a "working baseline" is the way to go (so please forget I brought them
> up :-). Insead, I suggest that we use the "auto-version" property on
> the baseline selector to indicate that Subversion will "auto-baseline"
> the repository whenever there is a checkin.
We can do this, but I'm a little wary that auto-version would imply that a
client can monkey with the baseline selector. I can always punt attempts,
though, with a 409 or something.
[ and as I mentioned, I don't see much use for the selector in the system; I
think there'd be only one and it would always be pointing at the latest
baseline. ]
> On a related topic, since you want the new "baseline" to be
> visible as soon as it is created, I believe that what subversion
> needs is not an "atomic activity checkin", but rather an
> "atomic activity checkin and merge". This would be an extension
> to the MERGE operator, rather than an extension to the CHECKIN
> operator. This is the way I've written it up for the 10-11
> draft. Please let me know if this works for you.
Per the thread on the DeltaV list: yes, this appears to work great.
>...
> > - how a client downloads a tree of resources from that "version"
>
> They run a command line such as:
>
> $ svn checkout http://www.lyra.org/repos/my-project
>
> [ checkout meaning "get"; not a DeltaV "checkout" ]
>
> Periodically, they will do:
>
> $ svn update
>
> This will update the files in the current directory from its corresponding
> location on the server.
>
> My question was more protocol related ... in other words, what sequence
> of GET requests would you be sending to the server (in particular, what
> will the request-URL be for those GET's).
The initial checkout is a PROPFIND to recurse over the repository. The
PROPFIND fetches the following properties: DAV:activity-collection-set (when
we go to commit, where do we create the activity?), DAV:resourcetype (is the
member a collection to recurse on?), DAV:target (get the URL for the version
resource), and DAV:version-name (get the revision number).
[ per the thread on the DeltaV list, this may become a REPORT so that I can
fetch that version-name ]
When the version URLs come back, then I do a GET on those.
An "update" involves sending a picture of the client state to the server,
the server responds with informatino on what is out of date, then the client
sends a bunch of GET requests to get the updated content (and PROPFINDs to
fetch properties (SVN's model includes property management)).
We will also be employing the Internet Draft regarding fetching of diffs.
We'll basically ask the server "I've got v5, give me a diff up to v7".
> BTW, I assume that if the current directory has version-controlled
> sub-directories, I assume that they will be updated as well?
Yup. This is the default, and a flag exists to update without recursing.
> > - is there a "default version" and how does a cient specify it
>
> The default is the latest. However, we also allow the client to fetch
> specific versions, fetch by date, fetch by label, etc. They could end up
> with a real mess if they so chose :-)
>
> Hopefully, you will use the baseline protocol instead of the label protocol
> (I believe it is a much better fit for Subversion).
It looks that way. We have been viewing labels as using one of two
mechanisms:
1) attach a label to the (abstract) revision
[ this would be labelling the baseline itself; how would you propose
doing this without labels? create a baseline selector named "mylabel"
that is targeted at the appropriate baseline? ]
2) do a copy-by-reference to a location decided upon out-of-band as holding
the "labeled" revisions. e.g. copy /trunk /labels/1.0a1
Note the creation of a baseline selector called "mylabel" is very similar to
our option (2). You put the thing "label-thingy" into a predefined area.
The nice thing about the copy-by-ref is that you can go into a labeled tree
and make patches. Can't really do that with a baseline.
> But in any event,
> when they do ask for some file or directory, will the pathname they specify
> be wrt the current namespace on the server, or the old namespace identified
> by that label/baseline? In other words, if they ask for:
> the version of file "/x/y/z.c" from baseline/label "release-4"
> is the path "/x/y/z.c" interpreted in the current server namespace or
> in the "release-4" namespace?
We would map "release-4" to the revision number, and then select "/x/y/z.c"
from that revision (presuming it existed at that path). So it would be the
"old namespace".
Oh, heck. We tossed the Target-Selector header. That's gonna make it hard to
select specific revisions. Gonna have to think on this one.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:18 2006