Re: new auto-version value

This new auto-version value only makes sense if the "checkin"
operation is used to promote a change in the workflow.  This is
probably non-optimal, since it doesn't let a client save an
intermediate state of the resource in the version history
(i.e. before it is ready to publish).  In addition, a step
in the workflow often requires changing multiple resources,
so you can't really infer from one being checked-in that the
task is complete.  So I would be against encouraging this 
model in the standard (and therefore would not
be in favor of standardizing on this new value).

WRT Lisa's question, he doesn't want the user to have to go to
the external state-manipulation tool to start a modification,
but he does expect the user to have to go to the external
state-manipulation tool to say "I'm finished with this task".
I agree that this is reasonable, but I'm against standardizing
on "checkin" to mean "I'm finished with this task".

Cheers,
Geoff

Lisa wrote on 06/18/2004 10:56:31 AM:
> I'm a little confused.  If you don't want the user to have to go to the 
> external state-manipulation tool, then why not use 
> checkout-unlock-checkin?  I would think you would want the checkin to 
> happen when editing is done, to publish the state.  Also note that the 
> state is "published" regardless, in that any changes made by any client 
> are visible on the resource checked out, whether or not it's checked in 
> again -- it seems pretty clear in this case you're talking about 
> in-place checkout.
> 
> The auto-version property is a bit of a hack to deal with 
> non-DeltaV-aware clients that can never know when to check out and 
> check in.  Adding more values to this property runs a risk of confusing 
> DeltaV clients that are aware of this property but only know the values 
> in the initial standard.  OTOH I'm not aware of any clients at all that 
> use the value of this property as yet so it would be good to hear if 
> there are any.

> On Jun 18, 2004, at 6:14 AM, Juergen wrote:
> > the auto-version property can currently hold 5 different values: 
> > Empty, checkout-checkin, checkout-unlock-checkin, checkout and
> > locked-checkout.
> >
> > I would like to propose a new value, named something like: 
> > checkout-ignore-unlock. It will carry the same semantics as the
> > checkout value, but an unlock command will not issue an implicit 
> > check-in command, instead the resource stays in the checked-out
> > state and an explicit check-in command is required.
> >
> > Use-case:
> >
> > A document is controlled by a workflow process. Creating a document 
> > takes this document in the initial-author state, in which only
> > explicit check-in command should create new versions. If this newly 
> > created resource is implicitly put under version-control and
> > the auto-version property is set to the new suggested value, we can 
> > receive this behaviour. Now the document can be modified
> > either with an http client (via put) or with a WebDAV client (Lock - 
> > Put* - Unlock) and still the resource is never implicitly
> > checked-in.
> > The same effect could be reached by an explicit check-out, but this 
> > will require an additional user interaction to issue the
> > check-out command, which we do not want to expose. Our user is then 
> > only required to use our state manipulation GUI tool, in case
> > of a real state change. The creation and manipulation of a new 
> > resource will feel like modification on the hard disc: create it,
> > modify it (with any tool) and then publish or change the state with an 

> > additional tool.
> >
> > Does this make a more general sense, or would you think this is a too 
> > specific requirement to go into any new version of the
> > delta-v standard?