Re: auto-version-values
Stefan, Stefan Burkard wrote on 07/12/04 11:00 AM: ---> ok, thanks for the advice. additionally i saw that the double-version only occurs when i first put in the document. when i put in a new version of an existing doc, it just creates ONE new version. Hmm, maybe this wasn't what I thought it was, but I guess that might depend on which client you used to create the document. I think I'd only ever seen 1 version created myself, but I honestly wasn't paying that much attention. just two other questions: - what are the consequences for dumb-client-documents that are checked out (automatically), but not checked in (manually) again? The consequence would be that a dumb client would never be able to actually create a new version of your document. You would have to perform the checking from a "smart client". This is normally not a problem if you have some sort of CMS/workflow interface to control the checkin features. You could leverage the "ease of use" of web folders or the KDE webdav:// protocol for day-to-day updates rather than a clunky web interface. I have had locking issues with dumb clients though, so if something gets locked by a smart client after an auto-checkout it will automatically get checked-in when the lock is removed again from the smart client. This is per the spec, but not always desired program behaviour. Long and the short of it, use a smart client for all checkout/checkin/uncheckout/locking. - what is the versioncontrol-method for? to activate and disactivate version-controlling on a document? If you don't use the "auto-version-control" parameter, yes, this is the method that would be called to place a resource under version control. We had an earlier discussion about how to take a resource out of version control and I think the consensus was you "couldn't". I think you would have to create a new resource that was specifically not under version and fill the contents/metadata from the last version. I have spent quite a bit of time investigating how all of these properties work with or against each other. The gist of everything is that dumb clients just mess everything up or make things more complicated. The only upside is easier use by the end user because you can have drag-drop, remote editing, remote saving, etc. I think you are wading your way through :) Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: auto-version-values
Tim Frank wrote: If you leave the auto-version parameter blank, empty, no value then NOTHING will happen automatically. I will mention that you should be careful with understanding how these parameters work with "dumb" webdav clients such as Windows WebFolders. The dumb behaviour is to automatically overwrite whatever is "live" as there is no checkout/checking issued. I would recommend using the "checkout" option for that reason, as a safeguard. ---> ok, thanks for the advice. additionally i saw that the double-version only occurs when i first put in the document. when i put in a new version of an existing doc, it just creates ONE new version. just two other questions: - what are the consequences for dumb-client-documents that are checked out (automatically), but not checked in (manually) again? - what is the versioncontrol-method for? to activate and disactivate version-controlling on a document? There is a duplicate of the file created in history to allow the uncheckout command to function. Uncheckout is like undo. You can checkout a file, do 20 changes on it, then decide "No, I really don't want to save those changes for this version", so you issue the uncheckout command to rollback to the last good copy from the history. ---> understand, thanks a lot! stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: auto-version-values
Hello Stefan, Adding to Tim's response, the propatch commands does not change the file content, but just it's metadata, witch is also being versioned but in the associated xml file of versioning, inside the metainfo store. It's pretty easy to confirm this if your metadata store is a txfilestore. Hope this helps, Miguel Figueiredo -Original Message- From: Tim Frank [mailto:[EMAIL PROTECTED] Sent: terça-feira, 7 de Dezembro de 2004 14:38 To: Slide Users Mailing List Subject: Re: auto-version-values Stefan, If you leave the auto-version parameter blank, empty, no value then NOTHING will happen automatically. I will mention that you should be careful with understanding how these parameters work with "dumb" webdav clients such as Windows WebFolders. The dumb behaviour is to automatically overwrite whatever is "live" as there is no checkout/checking issued. I would recommend using the "checkout" option for that reason, as a safeguard. There is a duplicate of the file created in history to allow the uncheckout command to function. Uncheckout is like undo. You can checkout a file, do 20 changes on it, then decide "No, I really don't want to save those changes for this version", so you issue the uncheckout command to rollback to the last good copy from the history. Hope that helps. Tim Stefan Burkard wrote on 07/12/04 09:23 AM: > hi slide-users > > ok, because my post about versioning ends up in a huge discussion about > other things, i make a new one :-) > > > i'm now a step ahead (thanks to warwick burrows). i set the following in > domain.xml: > checkout > true > > when i put a new file in the repository i do a put, and right after > that, i'm doing about 20 proppatches. finally, i do a manual checkin. > > result: 2 (equal) versions in "history" and a current one in "files". i > guess that i always have the current version in history too, have i? > > question: why have i got two equal versions in history? are they created > on (automatical) checkout and (manual) checkin? > > and second question: warwick burrows wrote "... disable auto-versioning > altogether and do both checkout and checkin yourself..." > how can i do this? set "auto-version-control" to false or "auto-version" > to an empty string? > > thanks and greetings > stefan > > > - > 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]
Re: auto-version-values
Stefan, If you leave the auto-version parameter blank, empty, no value then NOTHING will happen automatically. I will mention that you should be careful with understanding how these parameters work with "dumb" webdav clients such as Windows WebFolders. The dumb behaviour is to automatically overwrite whatever is "live" as there is no checkout/checking issued. I would recommend using the "checkout" option for that reason, as a safeguard. There is a duplicate of the file created in history to allow the uncheckout command to function. Uncheckout is like undo. You can checkout a file, do 20 changes on it, then decide "No, I really don't want to save those changes for this version", so you issue the uncheckout command to rollback to the last good copy from the history. Hope that helps. Tim Stefan Burkard wrote on 07/12/04 09:23 AM: hi slide-users ok, because my post about versioning ends up in a huge discussion about other things, i make a new one :-) i'm now a step ahead (thanks to warwick burrows). i set the following in domain.xml: checkout true when i put a new file in the repository i do a put, and right after that, i'm doing about 20 proppatches. finally, i do a manual checkin. result: 2 (equal) versions in "history" and a current one in "files". i guess that i always have the current version in history too, have i? question: why have i got two equal versions in history? are they created on (automatical) checkout and (manual) checkin? and second question: warwick burrows wrote "... disable auto-versioning altogether and do both checkout and checkin yourself..." how can i do this? set "auto-version-control" to false or "auto-version" to an empty string? thanks and greetings stefan - 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]
