From: Greg Stein <gstein@lyra.org>
> ... I believe (based on the design document and
> some comments you have made) that the "baseline" protocol would be a
> good fit for Subversion's notion of "a version of the whole
> repository".
I took a quick look at baselines the other day, and yes: they might apply
somewhat. At least from the standpoint of fetching a baseline. Operating
against one is a bit more suspect... (see below)
For the moment, I'm going to be ignoring baselines. I suspect they will be
added in a future version of SVN, when we round out the DeltaV support (SVN
1.0's DAV support will probably be pretty tuned to the minimum that the SVN
system requires; future revs will increase interop).
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.
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 :-)
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
set of all (repository) versions
=> baseline history
the thing that identifies what (repository) version is current
=> baseline selector
> We would have to allow you to "checkout" against a
> working baseline, and then you'd get your "atomic checkin" when you
> checked in the working baseline (which creates a "new version" of the
> entire repository). You'd still have an "activity" for each baseline,
> that represents the "change-set" of files modified to create that new
> baseline.
This would certainly be an alternative. But I can also avoid baselines and
just check in an activity and be done with it :-).
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.
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.
[ the flip side of the coin is that adding baseline support could be nice
for other clients who want to use baselines ]
Yes.
> - 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).
BTW, I assume that if the current directory has version-controlled
sub-directories, I assume that they will be updated as well?
> - 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). 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?
Cheers,
Geoff
Received on Sat Oct 21 14:36:17 2006