Re: Working Resource Issues ...

johnhall@evergo.net wrote:
> prompted by completely different understandings of what a
> "WORKING-RESOURCE" is and should mean.
> 
> I just thought it was a bit-bucket where the user could store his state
> until he was finished.  Check out VCR, get bit bucket, modify bit
> bucket, Check In.  The critical difference between Check-Out-In-Place
> and Check-Out-Working-Version was the visibility of the bit bucket to
> other users.  In-Place, they can see it.  Working-Version, they can't.
> 
> I've also mentioned that I'm concerned with 3rd party emulation.  The
> 3rd party has a 'working version', and that is exactly how they
> implemented the concept.
Yes, I know tools which have a 'working version'. But this means that
a version has a state 'working' (modifiable) and finally 'frozen'.
More complexity that I would like to avoid. You can get the same result
by having a working resource and a following UPDATE.
I prefer the simpler concept in this case.

> 4.1.3  DAV:checkout-invisible
> Normally, edits made on a resource while checked out are visible to
> other users.  If checkout-invisible is specified, however, other users
> will only see the last checked-in version.  A client is encouraged to
> see this feature as "lite" version of WORKING-RESOURCE which leaves the
> VCR in the checked-out state.
You say you don't need UPDATE (BTW, I read with great interest your 
'A compelling use case ...' a while ago. When I have time I will comment
on it, because I'm only a hobby deltaver unlike some other people who do
it by profession :-) so here I say that I don't need this invisible thing.
Because I get it by using a workspace. And in addition the workspace has
the advantage that I can tell a selected few where they find the workspace
where I'm doing my secret stuff.
I dislike it if there are too many ways to achieve the same result.
(OK, I admit I'm a purist sometimes). But this makes things difficult
for the DAUs (dümmster anzunehmender User, free translation to English:
dumbest imaginable user). Sure, versioning isn't trivial but many tools
nowadays aren't accepted by developers because they give them a flood of
features they drown in. So we should try to avoid too much redundancy.
Because I probably won't have time to write a long comment to John's
'A compelling use case ...' just a short statement from what I still
remember.
Is seems that you describe a very simple use case. A resource
is a resource and a recource and this resource has versions. So if
you delete your working resource the versions history also can go down
the closet.
But I guess (Perhaps I'm wrong) that most of the people discussing here
have more complex problems we want to solve.
We have thousands of source files which we have to freeze in baselines.
Some resources are contained in overlapping baselines. Just mention one
point. Baselining of multiple resources already begins with your
personal website.
So even if you delete a resource from your work package some versions
of it will still be necessary for other work packages or being contained
in other baselines. You can't delete these versions just because
YOU don't need them anymore.
You talk about your typing pool. So isn't it imaginable that a typist
suddenly thinks: Hey, the changes I made today are wrong. Let's go back to
and earlier version (Perhaps not the last one). That's what UPDATE is for.
So at last my question: Couldn't agreee to implement UPDATE ?
Not that complex and uncommon I guess (co -r <filename>)
Perhaps we then could stop some threads which threaten to make the spec
more complex.

Cheers, Edgar

P.S. Will there be any DeltaV action on the upcoming IETF in London ?
-- 
edgar@edgarschwarz.de                    http://www.edgarschwarz.de
*          DOSenfreie Zone.        Running Active Oberon.         *
Make it as simple as possible, but not simpler.     Albert Einstein

Received on Thursday, 21 June 2001 15:47:16 UTC