- From: <Edgar@EdgarSchwarz.de>
- Date: Wed, 28 Mar 2001 15:41:06 -0500
- To: ietf-dav-versioning@w3.org
- Cc: Edgar@EdgarSchwarz.de
> > The third proposed simplification was to defer the > > "Update Option", with the intention of leaving it out > > of the protocol unless its addition is more strongly > > motivated than it is currently. In particular, if you > > want to expose an older version of a VCR, you can just > > check out that VCR, copy that older version into the > > checked-out resource, and then check it back in. This > > has the added advantage that this does not block future > > work on a linear versioning server, the way an UPDATE > > would (i.e. you can only check out the tip in a linear > > versioning server). It also has the advantage that it > > is more compatible with the baseline and activity > > features, that want to define states as merges of > > baselines and activities, rather than manipulations of > > individual versions. > > > > Any objections? > > I strongly object to this one. If you have any respect for version history > then using UPDATE to expose the older version of a vcr is *significantly* > different to extending the tip with an equivalent version. I agree. BTW, could you expose an older version in a workspace without UPDATE ? Cheers, Edgar -- edgar@edgarschwarz.de http://www.edgarschwarz.de * DOSenfreie Zone. Running Native Oberon. * Make it as simple as possible, but not simpler. Albert Einstein
Received on Wednesday, 28 March 2001 15:41:09 UTC