- From: Konstantin Knizhnik <KKnizhnik@togetherlab.com>
- Date: Wed, 12 Dec 2001 01:18:00 +0300
- To: Edgar@EdgarSchwarz.de
- CC: ietf-dav-versioning@w3.org
Hello Edgar, Wednesday, December 12, 2001, 12:46:20 AM, you wrote: EEd> Konstantin Knizhnik <KKnizhnik@togetherlab.com> wrote: >> So, in few words, I do not understand how to do the following >> operation: >> - I have some project (version-controlled-collection) in some workspace >> (for example /ws/his/project1) >> - I want to place this project (copy all its resources) in my workspace /ws/my EEd> In short: have a look at BASELINE-CONTROL. EEd> - Do your work in /ws/his/project1. EEd> - Create a configuration by BASELINE-CONTROL EEd> - Check it in and you have a baseline (containing versions) EEd> - Then checkout the baseline at /ws/my So the only way to do it - is to place source collection under baseline control??? But what is the result of applying VERSION-CONTROL method with <DAV:version> refers to version-controlled-collection? It will create version-controlled resource in the target workspace for this collection iself but not for its members, right? What in this case is the result of PROPFIND with Depth=infinite applied to such version-controled-resource? Is there any good motivation for restricting VERSION-CONTROL source to be a version and not a version-controlled-resource, which capture information about the resource version and workspace to which it belongs? It seems to me that the current model of version-control method for existed version history is contradicting and not clear... If the only way of importing information in workspace from other workspaces is baseline, then we should prohibit version-control method for existed version history at all. Otherwise, version-control method should be able to correctly place the whole specified subtree in the target workspace. EEd> Cheers, Edgar -- Best regards, Konstantin mailto:KKnizhnik@togetherlab.com
Received on Tuesday, 11 December 2001 17:15:22 UTC