Versioning and locking question

[James Higginbotham <jh...@betweenmarkets.com>]

Hi,
 
I am trying to build a domain model which will basically simulate the
same steps needed to edit a file as visual source safe would:
Checkout->edit->checkin new version (content + properties)->release
lock. I'm trying to read the DeltaV spec and setup Slide to do this, all
via the DAV/DeltaV HTTP transport. I may be misunderstanding the
specifications, but it seems like I should be able to do the following
over DAV: 
 
PUT (an initial version of a file) - unlocked
CHECKOUT - locked by <user>
PUT then PROPPATCH - still locked by <user> but content and properties
updated
CHECKIN - lock released and new version created
 
I noticed that with auto-version set to checkout-checkin, it will not
actually lock on a CHECKOUT - I want this to happen so that other users
don't attempt to lock and edit the file. I changed auto-version to use
locked-checkout, but I cannot do a simple PUT to create a new file as it
says I am not allowed (not sure what I'm missing here - am I to lock the
folder for a new resource??). I then tried setting auto-version to
keep-checked-out and call WebdavResource.checkoutMethod() there is no
lock set. If I create a write lock instead of checking it out the PUT is
refused as it says its 'locked' (but locked by the same user as the one
doing the PUT). From the spec, page 17:
 
      Automatically checkout the resource, perform the modification, and
      then leave the resource checked out.  If the resource is write-
      locked, it will be automatically checked in when the write-lock is
      removed, but an explicit CHECKIN operation (see Section 4.4) is
      required for a non-write-locked resource.  This minimizes the
      number of new versions that will be created by a versioning
      unaware client, but only a versioning aware client can create new
      versions of a non-write-locked resource.
 
In interpreting this, I read this as a CHECKOUT and PUT is allowed, then
either CHECKIN or kill/expire the lock. What am I missing here? Is it my
understanding of DeltaV or a different approach I need to take under
Slide to make my scenario work? Here is the pseudocode of what I want to
do using my domain model and typical user scenario from a Junit test I
have (this matches the DAV commands I would send):
 
 aFolder.createFile(TEST_FILENAME, TEST_FILE_DESCRIPTION,
TEST_FILE_TYPE, TEST_FILE_CONTENT); // initial PUT
 originalVersion = resource.getLatestVersion();
 FileVersion checkedOut = resource.checkout(); // CHECKOUT
 assertTrue(foundFile.isCheckedOut());
 checkedOut.setContent("changed");
 resource.checkin(checkedOut); // CHECKIN
 assertTrue(!foundFile.isCheckedOut());
 FileVersion updatedVersion = foundFile.getLatestVersion();
 // updatedVersion should have new content now...
 
Thanks,
James

Re: Versioning and locking question

[Ingo Brunberg <ib...@fiz-chemie.de>]

Hi James,

from your description I guess the auto-versioning model
"locked-checkout" comes closest to your requirements, as this is the
only model that couples the write lock with the checkout so
tightly. It's just the other way round - instead of calling CHECKOUT
and CHECKIN you have to call LOCK and UNLOCK to create a new version.
I have not tried this myself, but I guess to PUT a new resource you
have to lock it before it really is created (a locked null
resource). You can quickly check if that works if you use cadaver as a
client, as it working that way. In cadaver, say "edit file.xyz", save
it and you will see if it succeeds.

Regards,
Ingo

> Hi,
> =20
> I am trying to build a domain model which will basically simulate the
> same steps needed to edit a file as visual source safe would:
> Checkout->edit->checkin new version (content + properties)->release
> lock. I'm trying to read the DeltaV spec and setup Slide to do this, all
> via the DAV/DeltaV HTTP transport. I may be misunderstanding the
> specifications, but it seems like I should be able to do the following
> over DAV:=20
> =20
> PUT (an initial version of a file) - unlocked
> CHECKOUT - locked by <user>
> PUT then PROPPATCH - still locked by <user> but content and properties
> updated
> CHECKIN - lock released and new version created
> =20
> I noticed that with auto-version set to checkout-checkin, it will not
> actually lock on a CHECKOUT - I want this to happen so that other users
> don't attempt to lock and edit the file. I changed auto-version to use
> locked-checkout, but I cannot do a simple PUT to create a new file as it
> says I am not allowed (not sure what I'm missing here - am I to lock the
> folder for a new resource??). I then tried setting auto-version to
> keep-checked-out and call WebdavResource.checkoutMethod() there is no
> lock set. If I create a write lock instead of checking it out the PUT is
> refused as it says its 'locked' (but locked by the same user as the one
> doing the PUT). From the spec, page 17:
> =20
>       Automatically checkout the resource, perform the modification, and
>       then leave the resource checked out.  If the resource is write-
>       locked, it will be automatically checked in when the write-lock is
>       removed, but an explicit CHECKIN operation (see Section 4.4) is
>       required for a non-write-locked resource.  This minimizes the
>       number of new versions that will be created by a versioning
>       unaware client, but only a versioning aware client can create new
>       versions of a non-write-locked resource.
> =20
> In interpreting this, I read this as a CHECKOUT and PUT is allowed, then
> either CHECKIN or kill/expire the lock. What am I missing here? Is it my
> understanding of DeltaV or a different approach I need to take under
> Slide to make my scenario work? Here is the pseudocode of what I want to
> do using my domain model and typical user scenario from a Junit test I
> have (this matches the DAV commands I would send):
> =20
>  aFolder.createFile(TEST_FILENAME, TEST_FILE_DESCRIPTION,
> TEST_FILE_TYPE, TEST_FILE_CONTENT); // initial PUT
>  originalVersion =3D resource.getLatestVersion();
>  FileVersion checkedOut =3D resource.checkout(); // CHECKOUT
>  assertTrue(foundFile.isCheckedOut());
>  checkedOut.setContent("changed");
>  resource.checkin(checkedOut); // CHECKIN
>  assertTrue(!foundFile.isCheckedOut());
>  FileVersion updatedVersion =3D foundFile.getLatestVersion();
>  // updatedVersion should have new content now...
> =20
> Thanks,
> James
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org