- From: <Edgar@EdgarSchwarz.de>
- Date: Thu, 21 Jun 2001 15:47:13 -0400
- To: ietf-dav-versioning@w3.org
- Cc: Edgar@EdgarSchwarz.de
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