[EMAIL PROTECTED] wrote:

-----Original Message-----
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
Sent: Monday, March 29, 2004 17:06
To: Slide Developers Mailing List
Subject: Re: How about RC1?


Oliver Zeigermann wrote:


[EMAIL PROTECTED] wrote:


I guess, there actually is no bug like this. The real bug

is #26913.


I thought it might be good to change the location of the

versioned


content, e.g.

/files/test/file1.txt

would be versioned in

/history/files/test/file1.txt

instead of

/history/10/h3

or similar locations. This would make it possible to

actually find


versioned
content ever if the client has no idea about versioning.

Comments?



I wasn't really aware of bug #26913 ... I am obviously the

originator


of this problem, so sorry for not reacting sooner! (Too many other less funny problems :( ) ... I'll take a look ASAP.

Concerning the proposal of letting /files/test/file1.txt

be versioned


in /history/files/test/file1.txt ... I'm not sure whether

I completely


understand. Would /history/files/test/file1.txt be a folder representing the VHR and containing the VRs, e.g. the VR /history/files/test/file1.txt/1.17 ?


Yes. This was my initial idea. The displayname of 1.17

would be file1.txt


There are several things to consider:

1) There may be multiple VCRs associated to the same VHR.

Currently, a


VHR at /history/10 may have associated VCRs at

/files/test/file1.txt,


/workspace/john/files/test/myfile.txt and /workspace/phil/files/test/aaa.txt

I am no expert in all this. Are /workspace/john/files/test/myfile.txt and /workspace/phil/files/test/aaa.txt versions of /files/test/file1.txt checked out into a workspace? I thought they would have to have the same name (file1.txt) in this case?


If they are checked out versions, you could still all map to /files/test/file1.txt, right?


No, /workspace/john/files/test/myfile.txt and /workspace/phil/files/test/aaa.txt are not versions of /files/test/file1.txt. They are simply to resources under version control (=VCR) which share the same history (=VHR). Each VCR may reference a different "target" version (=VR) whithin the history in question.

Also, in DeltaV, resources are not "checked-out into a workspace". A workspace can be populated with resources (both, versioned and not versioned). To add a VCR to a workspace for an existing VR you dont use COPY but a special form of the VERSION-CONTROL command. VCRs in a workspace can be in both states: checked-in or checked-out.

No, multiple VCRs associated to the same history are not required to have the same name.

Man, that's complicated! Anyway, I think I finally understood! Thanks for taking the time :)


Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to