version control basics

[ChadDavis <ch...@gmail.com>]

The specification says that checked-out means that "The checked-out
state indicates to the repository and other clients that the latest
version of N is 'being worked on' and will typically be checked-in
again at some point in the future, thus creating a new version."

This language seems to suggest that the semantics of the API are a
perfect match for common sense use cases of a version control
supporting CMS.  But I can't quite get it to work out . . .

Edit Document:

1) checkout  ( now, the document is checkedOut; in other words, other
users can't edit )
2) make changes
3) checkin ( now, the document is open to edit by other users with the
proper permissions )

In this context, the language from the spec makes sense.  Note,
however, that this model requires a new version be added to the
history for EVERY edit session.  I don't think it makes sense to
create an official version of the document for each editing session,
but the only way I can move the document back to the "checked in"
state, is to use the checkin method that creates a new version.  This
means that either I give up on the semantics of using "checked out" as
a way of informing other users that they aren't allowed to edit the
document because "it's being worked on", or i accept the creation of
an official version each time I have an edit session.

I've read on this list, that some developers keep the document always
in the checkedOut state and only move to the checked in state when
committing an official version of the document.  After which they
immediately checkOut the document again.  This works for me, but seems
to be a waste of the entire concept of "checked out".

Can someone please provide insight into the proper use of this API?

Re: version control basics

[Fabián Mandelbaum <fm...@gmail.com>]

Hello, jumping in because I'm interested on this one too.

IMVHO, the locking API is the way to go, to complete disallow
modification of the node "from the outside".

At least that's the way WebDAV editors try to work with the content
store, by issuing a DAV LOCK request in the hopes that the content
store will lock the file.

As for checkin/checkout and crazy users (those that issue a Save
command on their DAV-enabled editor every other minute)... there's not
much you can do I guess?

On Tue, Nov 2, 2010 at 1:39 PM, ChadDavis <ch...@gmail.com> wrote:
> On Tue, Nov 2, 2010 at 10:29 AM, Jukka Zitting <jz...@adobe.com> wrote:
>> Hi,
>>
>> From: ChadDavis [mailto:chadmichaeldavis@gmail.com]
>>> I've read on this list, that some developers keep the document always
>>> in the checkedOut state and only move to the checked in state when
>>> committing an official version of the document.  After which they
>>> immediately checkOut the document again.  This works for me, but seems
>>> to be a waste of the entire concept of "checked out".
>>
>> Would you also call Subversion a wasteful version control system since it keeps working copies always in a
>> "checked out" state?
>
> Sorry, I did not mean to imply that it was a pointless feature.  On
> the contrary, I'm looking for advise on how to make use of it.
>
> In particular, I'm looking to implement locking of a document by an
> author.  I'm trying to decide between whether the locking api or the
> version control api's checked-out state are more appropriate.  I've
> read a lot of older threads on this list, but couldn't find a
> satisfactory explanation.
>



-- 
Fabián Mandelbaum
IS Engineer

RE: version control basics

[Jukka Zitting <jz...@adobe.com>]

Hi,

From: ChadDavis [mailto:chadmichaeldavis@gmail.com]
> In particular, I'm looking to implement locking of a document by an
> author.  I'm trying to decide between whether the locking api or the
> version control api's checked-out state are more appropriate.  I've
> read a lot of older threads on this list, but couldn't find a
> satisfactory explanation.

If all you need is locking, then using the JCR locking feature is probably more appropriate than relying on the checked in / checked out states of JCR versioning.

The versioning feature only cares about the state of the versioned document, not about which user or client is accessing it. To summarize: nobody can modify a checked in document, and everyone can modify a checked out document.

The locking feature does care about who is accessing the document; only the holder of an active lock can modify a document.

So if you want per-author locking, the JCR locking feature seems like the most appropriate solution.

BR,

Jukka Zitting

Re: version control basics

[ChadDavis <ch...@gmail.com>]

On Tue, Nov 2, 2010 at 10:29 AM, Jukka Zitting <jz...@adobe.com> wrote:
> Hi,
>
> From: ChadDavis [mailto:chadmichaeldavis@gmail.com]
>> I've read on this list, that some developers keep the document always
>> in the checkedOut state and only move to the checked in state when
>> committing an official version of the document.  After which they
>> immediately checkOut the document again.  This works for me, but seems
>> to be a waste of the entire concept of "checked out".
>
> Would you also call Subversion a wasteful version control system since it keeps working copies always in a
> "checked out" state?

Sorry, I did not mean to imply that it was a pointless feature.  On
the contrary, I'm looking for advise on how to make use of it.

In particular, I'm looking to implement locking of a document by an
author.  I'm trying to decide between whether the locking api or the
version control api's checked-out state are more appropriate.  I've
read a lot of older threads on this list, but couldn't find a
satisfactory explanation.

RE: version control basics

[Jukka Zitting <jz...@adobe.com>]

Hi,

From: ChadDavis [mailto:chadmichaeldavis@gmail.com]
> I've read on this list, that some developers keep the document always
> in the checkedOut state and only move to the checked in state when
> committing an official version of the document.  After which they
> immediately checkOut the document again.  This works for me, but seems
> to be a waste of the entire concept of "checked out".

Would you also call Subversion a wasteful version control system since it keeps working copies always in a "checked out" state?

There are valid cases where both checked in and checked out states are needed, so the JCR standard supports both states. But you're free to decide how to use these features.

BR,

Jukka Zitting