RE: checked-out VCC (was: Re: Versioning TeleConf Agenda, 4/6/01 (Friday) 12-1pm EST)

In versioning, a good way of determining what the "state" of a
version-controlled resource consists of,
is to create a version of it, and see what is stored in that
version.  If you create a version (i.e. baseline) of a version-controlled
configuration, you see a snapshot of the state of all members of
the configuration rooted at the baseline-controlled collection.
I believe this is a compelling argument for the statement that
the state of the version-controlled configuration is the state of
the configuration rooted at the baseline-controlled collection
(also, that's what the protocol says :-).

Note that Greg and Edgar are making a different argument:
they agree that the state of the version-controlled configuration
is the state of the configuration rooted at the baseline-controlled
collection, but they argue that protocol should be changed to say
that the baseline-controlled collection
should not be modifiable while version-controlled configuration is
checked in (the protocol currently makes no such requirement).
I'll respond to that in a separate message.

Cheers,
Geoff

-----Original Message-----
From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]
Sent: Wednesday, April 11, 2001 4:42 AM
To: ietf-dav-versioning@w3.org
Subject: Re: checked-out VCC (was: Re: Versioning TeleConf Agenda,
4/6/01 (Friday) 12-1pm EST)




I guess it just depends on which perspective you take.
If you are looking at it from the baseline point of view then the
version-controlled configuration should remain checked-in, but if you are
looking at it from the baseline-controlled configuration then it should
remain checked out.

It can be argued either way, but I think of a version-controlled
configuration as being 'more closely associated with' the baseline -- but
don't ask me to give a good reason<g>
So I would expect the version-controlled configuration to be in a
checked-in state for most of the time, then be checked out and checked in
to capture the new baseline (i.e. the opposite of the proposal).

Regards,
Tim

Greg wrote:


On Mon, Apr 09, 2001 at 01:19:58PM -0400, Clemm, Geoff wrote:
> A version-controlled configuration is always associated with a
> baseline-controlled collection (and is used to capture the state
> of the configuration rooted at that baseline-controlled collection).
> Since you can always check-out/modify/check-in the members of the
> baseline-controlled collection, this effectively lets you modify
> that membership of that baseline-controlled collection, unconstrained
> by the current state of the associated version-controlled configuration.

In the above description, you're modifying the baseline-controlled
collection (BCC). You aren't modifying the VCC.

I still see no point in putting the VCC in a permanently-checked-out state.

If you're concerned about consistency between the BCC and the baseline
referred to by the checked-in VCC, then the answer is to make the BCC
readonly. Not to say the VCC is always checked out.

Checking out the VCC would then allow the BCC to be modified. I have no
opinion on whether a server can always (force) a VCC to remain checked out.
But the spec should not mandate that situation.

[ in Subversion, the VCC cannot be checked out and the BCC is readonly; you
  must use working resources to create a new baseline, all of which is then
  merged into the BCC and VCC ]

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

Received on Wednesday, 11 April 2001 08:10:29 UTC