[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?
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]
