Oliver Zeigermann <[EMAIL PROTECTED]> writes:
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?
Do you want to fix this in Slide 2.0 or should it be left to 2.1. It is probably not trivial and would require serious testing. On the other side, it changes the data format and that should be avoided between 2.0 and 2.1
I am for fixing this in 2.0.
Your proposal would address two other serious problems with versioning.
1) Performance problems due to a overcrowded /history directory. See http://thread.gmane.org/gmane.comp.jakarta.slide.user/2366
You have already checked in the fix proposed there, maybe accidently. The commit was on March, 14th...
2) AFAIK the connection to history is lost if a resource is deleted.
Really?
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...
Fine.
--------------------------------------------------------------------- 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]
