Re: Locking (was Re: CVS Transaction)

[Derek Price]

Paul Sander wrote:

> It can be done with intent mode locks and some simple manipulation of
> the RCS files.  Intent mode locks allow concurrent access by readers
> while copies of the RCS files are updated.  


Intent mode locks at the directory level exist on feature, but I believe
the issue that was raised is that if a client started a transaction, any
file they touched would be locked against write until the user typed
"end transaction".  I don't believe your answer avoids this.

It is one thing to put the repository's writabilty at the mercy of a
server working as fast as it can to finish a single task, but to put it
at the mercy of a user who might be interrupted by a phone call and
leave their office while still logged in is quite another.  Still, I
suppose this could be solved with configurable transaction timeouts or
ways admins could break a stalled transaction.

But, I can  think of two other ways to add transactions, at least for a
single CVS operation at a time, and one is pretty simple and the second
is at least simpler than the major rewrite you describe.

1)  Lean on the new commitids on feature.  If a commit fails part way
through, then use the commitids to back out the successful parts of the
commit as part of cleanup.

2)  Move the archive storage (i.e. RCS files), optionally (as configured
by a server admin), into a transaction-capable database like PostgresSQL
and lean on that.  All that would need to be replaced is the RCS API,
and it could be transparent to most of the program whether the "RCS"
functions it is calling reads from a file system or DB.  Then the only
new portion of the API visible to most of the program would be something
like RCS_start_transaction, RCS_end_transaction, &
RCS_abort_transaction, which would make the DB start/end/abort
transaction calls as necessary.

Regards,

Derek

-- 
Derek R. Price
CVS Solutions Architect
Ximbiot <http://ximbiot.com>
v: +1 717.579.6168
f: +1 717.234.3125
<mailto:address@hidden>