> -----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. > >> 2) A VCR /files/test/file1.txt versioned in > >> /history/files/test/file1.txt can be renamed or moved ... but the > >> history must stay because DeltaV prohibits moving or > renaming VHRs. I > >> could have renamed /files/test/file1.txt to > /files/test/file2.txt and > >> afterwards created a new resource /files/test/file1.txt. What name > >> does the history of the new /files/test/file1.txt get now? > > > > > > Hmmm, a move would be a delete followed by a create, right? > Thus the > > files to history mapping would be like: > > > > (1) /files/test/file1.txt --> /history/files/test/file1.txt/1.0 > > (2) /files/test/file2.txt (moved from (1)) --> > > /history/files/test/file2.txt/1.0 > > (3) /files/test/file1.txt (newly created) --> > > /history/files/test/file1.txt/2.0 > > > > Or is this nonsence? > > > >> > >> So, a name /history/files/test/file1.txt of a history > could end up not > >> being very meaninful after all. > > > > > > Because 1.0 in /history/files/test/file1.txt has got > nothing to do with > > 2.0? I see... Maybe it would still be better than > completely ananoymous > > paths? > > > > Opinions? > > > > Oliver > > > >> > >> Regards, > >> Peter > >> > >>> -----Original Message----- > >>> From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > >>> Sent: Monday, March 29, 2004 12:51 > >>> To: Slide Developers Mailing List > >>> Subject: Re: How about RC1? > >>> > >>> > >>> Martin Holz wrote: > >>> > >>> > >>>> Daniel Florey <[EMAIL PROTECTED]> writes: > >>>> > >>>> > >>>> > >>>>> The only bug that I know of that is a real showstopper is the > >>>>> versioning bug that prevents concurrent autoversioning and > >>> > >>> > >>> versioning > >>> > >>>>> more than 100 documents. > >>>>> > >>>>> If this bug is somehow fixed I'll vote for a release candidate. > >>>> > >>>> > >>>> > >>>> Which bug is this? I am running a server with thousands of > >>>> versioned documents, however with a modified VersionHelper. > >>> > >>> > >>> 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? > >>> > >>> > >>>> There is one bug in command line client, which causes > >>>> it to exit with a exception, if you type special characters > >>>> like $# . Maybe just one catch clause, but I don't know antlr. > >>> > >>> > >>> This is bug #27712, right? If so, I will fix it... > >>> > >>> > >>>> Otherwise a release candidate should be okay. > >>> > >>> > >>> Fine :) > >>> > >>> Cheers, > >>> > >>> Oliver > >>> > >>> > --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >> > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > >> . > >> > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > . > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
