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

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

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).

Cheers,
Geoff 


-----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-PUT = DELETE
UN-CHECKOUT = UNCHECKOUT
UN-CHECKIN = we don't want that in the protocol. Normally available at
			 the repository level I suppose.
UN-UPDATE = UPDATE
UN-MOVE = MOVE
So for most operations sort of a rollback is possible. Therefore I also
would
like to have it for VERSION-CONTROL. BTW my emphasis is more on
UNBASELINE-CONTROL.
See below.
So we have basic and advanced versioning. Could we add an "optional" part
including
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
perhaps
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
implemented.

> 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
(UNVERSION-CONTROL is
just it's little brother). It doesn't happen every day but once in a while I
found
that software projects with hundreds or thousands of files need some
redesign.
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
understand
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"
section
of 3253.
BTW, I'm writing DeltaV stuff for an exotic language called Oberon at the
moment.
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