From: Greg Stein <gstein@lyra.org>
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.
You may find that you want/need them when you try to do cross-repository
operations, but I agree sub-baselines should not be required for baseline
support.
BASELINE-CONTRL would be a no-op.
Yup. (It will be in our first implementation also ... we pick
which collections are baseline-controlled, not the client).
There would be a single baseline-selector and a single
baseline history per repository. There would be a baseline per
global-revision.
Yes.
Note that I was going to have a resource that corresponded to each
global-revision already. That resource would hold our "per-revision"
properties.
Yes, I thought so. If you marshall this as a DeltaV "baseline",
you'll actually get a non-trivial amount of interoperation with
other baselining clients.
> the thing that identifies what (repository) version is current
> => baseline selector
Yup. I don't think the selector would really be used, though.
If a client wanted to know (and perhaps store away somewhere)
what was the "current" repository revision, how would it find out?
If you marshalled this as a property of a "baseline selector"
resource (one per repository), then you'd get interoperability
at what I believe would be a very low cost.
>...
> 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.
409'ing attempts to monkey with the baseline selector is totally
reasonable. That's what you'll be doing anyway with attempts
to CHECKIN individual working resources, etc. A user would
get that message from a non-subversion client, and would try
something else (like MERGE, for example, which would work).
[ 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. ]
Yes, it is primarily there for interoperability.
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? ]
Yes, attaching a label to the baseline/abstract-revision is very
reasonable.
A baseline selector is always associated with a baseline-controlled
collection, so the baseline selector is actually DeltaV's way of
doing (2).
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
If you marshalled that as a
BASELINE-CONTROL /labels/1.0a1
instead of a COPY, you'd get interoperability with other DeltaV clients.
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.
Yes.
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.
With a baseline selector, you can though, since a baseline selector
is associated with a baseline-controlled collection, and you can then
do patches against that baseline-controlled collection (and merge them
back into your main repository when you wish).
> 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.
The Target-Selector header wouldn't have helped, since assumedly,
the user wants that name to be mapped against their possibly
mutated local namespace (which the server doesn't know about).
So unless the client tells the server what its local namespace
currently looks like (such as it does with an "update" request),
doesn't the client pretty much have to ask for each file version in a
separate request (which it can do, since it knows the file and
directory version URL's, from which it can get any other version from
the history of that file or directory).
In particular, if you download the version history URL whenever you
download a version, you can just use the baseline-version report to
get the version URL of the file version picked by an arbitrary
baseline.
With HTTP-1.1 theoretically keeping connections alive, would it be
that bad to request each file version URL separately?
But I'll stop here in case either you or I have no idea what I'm
talking about (:-).
Cheers,
Geoff
Received on Sat Oct 21 14:36:18 2006