Re: Versioning collections question

Thanks for the response. It all makes sense (or at least I think
it all makes sense :-)... but...

On Tue, Jun 26, 2001 at 01:18:22PM -0400, Clemm, Geoff wrote:
> So with a URL like /foo/a, how do you know which of the many possible
> bindings named "a" between /foo and some other resource are to be used?
> Unfortunately, the "independent binding" model breaks down in the
> presence of versioning.

I am sorry - are you saying a collection can have multiple bindings
to different resources using the same name? Or are you talking about
different versions of the same collection having different bindings
of "a" to other resources?

> I'm not sure what you mean by "get out" here.  A collection has
> members.  When that collection is under version control, you have to
> check the collection out in order to change the membership of that
> collection.  The membership of the collection is not changed by
> checking it out (or checking it in), it is changed by MOVE, COPY,
> UPDATE, etc.

My use of "get out" was a vague hand wavy thing in since "check-out"
had specific semantics in DeltaV and I was not sure if I meant
check-out or not. But its all sort of making sense.

However, the above leads me on to another question. If user A checks
out a version-controlled collection and adds a new file. User B then
checks out the same version-controlled collection and adds a different
new file. (I am thinking of a CVS like model here - I don't know the
correct DeltaV jargon for this yet.) Both users then try to check
in the resource. In CVS, the second commit might fail with a conflict,
or CVS might be smart enough to do the merge. In DeltaV, what is
expected to happen? I conflict report? A merge by the server? A merge
by the client doing the second commit?

>    ("I want to check out /foo and /foo/a/..., but not /foo/b" is not
>    possible since the container /foo will contain the "b" binding
>    so "b" will be visible).
> 
> Visibility is independent of whether or not something is checked out.
> When you check out /foo and /foo/a, then those two resources are
> checked out, and no others.
> 
>    I guess "b" does not have to be in the
>    "checked-out" mode or something - ie, read only (??).
>    I don't know if this is important.
> 
> Yes, it is important (it tells you what is currently checked out
> and therefore what is modifiable.

So just to clarify, if I check out /foo and /foo/a/ but not /foo/b,
then in my workspace(??), what resource type is /foo/b? I was reading
through the archives a bit and came across the term "version selector".
Is /foo/b a "version selector"?

Finally, Tim said:
> Just to confuse things more :-) a version-controlled collection can have a
> version-controlled internal member with the same name as a
> non-version-controlled-member, and they are considered distinct.  Again,
> this is all explained in Section 14.

Egad!

Hmmm. I think my eyes must have glazed over by the time I got to
section 14. I had better go read it again more carefully! It should
make more sense this time.

Thanks everyone for the feedback.

ajk

Received on Tuesday, 26 June 2001 20:38:34 UTC