Re: Re (2): Creating new version-controlled bindings referencing existing VHR's

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