> 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 ? 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 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? So, a name /history/files/test/file1.txt of a history could end up not being very meaninful after all. 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]
