W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2003

RE: Re (2): request for un-version-control feature

From: Clemm, Geoff <gclemm@rational.com>
Date: Mon, 3 Mar 2003 17:55:19 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED6CF@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org

OK, since there are three folks asking for UN-XXX-CONTROL,
I'm willing to withdraw my objection since I'm the only one

So now the main question is: should this go in the
next revision of 3253, or should it be a separate draft?
(Either one is OK with me).


-----Original Message-----
From: Edgar@EdgarSchwarz.de [mailto:Edgar@EdgarSchwarz.de]

"Clemm, Geoff" <gclemm@rational.com> wrote:
>    From: Julian Reschke [mailto:julian.reschke@greenbytes.de]
>    > From: Clemm, Geoff
>    > The main part of the question was: "Could you motivate the need
>    > to unversion-control a resource."  New standard protocol features
>    > do not come for free ... they introduce additional complexity
>    > into the protocol, especially for client and server
>    > implementations that try to fully implement the protocol (to
>    > maximize interoperability).
>    I wasn't actually asking for a "standard protocol feature". I was
>    looking for an agreement between those that *do* want that feature,
>    so that *their* servers can interoperate.
> OK, that wasn't clear before (there was a request earlier to get
> an UNVERSION-CONTROL method into the standard protocol).
I somehow like complete concepts. So I see:
UN-CHECKIN = we don't want that in the protocol. Normally available at
			 the repository level I suppose.
So for most operations sort of a rollback is possible. Therefore I also
like to have it for VERSION-CONTROL. BTW my emphasis is more on
See below.
So we have basic and advanced versioning. Could we add an "optional" part
UNVERSION-CONTROL and UNBASELINE-CONTROL for these systems who think they
need it ?
It needs to be written down somewhere to be agreed on.
When I have a look at my implementation it would be easy to implement. But
I don't see the problems yet :-)
No request body necessary. No depth problems. Perhaps a precondition
version-controlled-configuration-must-be-checked-out if baselines are also

> I personally would be willing to require that deleting a version
> history converts all version-controlled resources for that
> version-history into non-version-controlled resources,
Is that realistic ? Does the keeper of the version history know about all
the VCRs and version urls that exist perhaps on other servers ?

> Edgar: Does this also address your request for an UNBASELINE-CONTROL
> operation (i.e. if we defined that deleting the
> version-controlled-configuration causes the associated
> baseline-controlled collection to no longer be baseline controlled)?
No it doesn't. My interest is mainly in UNBASELINE-CONTROL
just it's little brother). It doesn't happen every day but once in a while I
that software projects with hundreds or thousands of files need some
So you want to rearrange your subconfiguration hierarchy. In this case I
don't want
to delete the baseline history. An UNBASELINE-CONTROL would be an easy to
concept (At least to me :-)
Also I can imagine to restore a baseline which I would like to publish on
CD with versioning info removed. 
And because (As I already mentioned before) I still think that it would be
easy to
do in my implementation I would like to have the option to do it.
To be able to be interoperable with other implementations it needs to be
defined somwhere. Because it's such simple stuff it would be overkill to
have another RFC. So I would prefer it to be described in a "optional"
of 3253.
BTW, I'm writing DeltaV stuff for an exotic language called Oberon at the
So it's not so important what I do :-)

Cheers, Edgar

edgar@edgarschwarz.de                  "http://www.edgarschwarz.de"
"http://www.edgar-schwarz.de/forum/oberon"    Running Active Oberon
Make it as simple as possible, but not simpler.     Albert Einstein
Received on Monday, 3 March 2003 17:55:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:48 UTC