As Tim has noted the correct approach for you is to either disable auto-versioning altogether and do both checkout and checkin yourself; or there is an auto-versioning configuration that automatically checks out for you but will leave the file checked out for you to checkin manually. Assuming of course that you're making all the property changes at one time and not progressively over a period of time :-) While the file is checked out any changes you make aren't visible to other users fetching the file or viewing its properties.
I've pasted in a section below from the DASL spec dicussing the auto-version parameter, the settings it can take and what each does. The whole spec is also here: http://ietf.org/rfc/rfc3253.txt Warwick 3.2.2 DAV:auto-version If the DAV:auto-version value is DAV:checkout-checkin, when a modification request (such as PUT/PROPPATCH) is applied to a checked-in version-controlled resource, the request is automatically preceded by a checkout and followed by a checkin operation. If the DAV:auto-version value is DAV:checkout-unlocked-checkin, when a modification request is applied to a checked-in version-controlled resource, the request is automatically preceded by a checkout operation. If the resource is not write-locked, the request is automatically followed by a checkin operation. If the DAV:auto-version value is DAV:checkout, when a modification request is applied to a checked-in version-controlled resource, the request is automatically preceded by a checkout operation. If the DAV:auto-version value is DAV:locked-checkout, when a modification request is applied to a write-locked checked-in version-controlled resource, the request is automatically preceded by a checkout operation. If an update to a write-locked checked-in resource is automatically preceded by a checkout of that resource, the checkout is associated with the write lock. When this write lock is removed (e.g. from an UNLOCK or a lock timeout), if the resource has not yet been checked in, the removal of the write lock is automatically preceded by a checkin operation. A server MAY refuse to allow the value of the DAV:auto-version property to be modified, or MAY only support values from a subset of the valid values. <!ELEMENT auto-version (checkout-checkin | checkout-unlocked-checkin | checkout | locked-checkout)? > <!ELEMENT checkout-checkin EMPTY> <!ELEMENT checkout-unlocked-checkin EMPTY> <!ELEMENT checkout EMPTY> <!ELEMENT locked-checkout EMPTY> > -----Original Message----- > From: Tim Frank [mailto:[EMAIL PROTECTED] > Sent: Friday, December 03, 2004 7:53 AM > To: Slide Users Mailing List > Subject: Re: example for versioning > > > Stefan, > > Not sure if you saw my previous post about the Domain.xml > settings for > the auto-version-control and auto-version properties. By default the > auto-version property is set to checkout-checkin which means every > modification makes a new version. You need to change this property if > you don't want automatic control of resource versioning, or a > different > kind. > > Tim > > Stefan Burkard wrote on 03/12/04 04:29 AM: > > > >> We discussed this recently on the list and I don't think > that there > >> is a Slide configuration that will let you do this. A file under > >> version control cannot have its properties changed without > checking > >> it out/in again which will increment the version number. > > > > > > well, i never want to change individual properties of the > file without > > putting a new version in the repository. > > > > all i want to avoid is that i get ONE version for EVERY property i > > patch > > on a new file. > > when i put a file in the repository and patch 20 properties > on it (right > > after putting it in), i get an actual and 19 old versions, > because every > > new property forces the creation of a new version. > > > > i'm sure there is a way to avoid this, isn't it? > > > > i guess my put-process is not the way it should... and i'm also > > guessing > > that the three methods checkin, checkout and versioncontrol > can help me, > > but how? > > > > 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]
