Re: Locking (was Re: CVS Transaction)

[Paul Sander]

On Sep 8, 2005, at 11:18 AM, Derek Price wrote:

> 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.

Depends on how it's implemented.  If the bracketed commands are stored 
and the actual transaction with the server begins when the user types 
"end transaction" then the condition you describe is avoided.  This 
could lead to other potential problems, e.g. if one bracketed command 
changes the state of the repository and subsequent commands rely on 
that state change to make decisions that direct further state changes.  
There are ways to mitigate this:  One is to disallow this type of 
decision making, another is to allow transactions only via some batch 
mode where user interaction is not permitted.

> 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.

How does this help with other state changes, e.g. the creation or 
migration of tags?

> 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.

But then we lose the human-readable property of the repository, which 
some consider to be one of CVS' greatest strengths.

The method that I propose addresses both of these concerns.  Thinking 
about it further, I think that the intent-mode and write-mode locks on 
module/branch pairs can be weakened further so that concurrent 
transactions can be permitted as long as the sets of RCS files involved 
in each one don't overlap.  This involves yet another trade-off in 
which transactions don't complete in the same order in which they 
initiate, which has implications when fetching by timestamp.  I don't 
have a good feel as to whether or not this would be a serious problem, 
though, given that other conditions provoke the same behavior.  But 
given the sparse and distributed nature of the locks created by this 
method would increase throughput even further.

Another strength of fine-grain, cheap locks like what I propose is that 
they fix a scalability problem that arises when a sandbox is populated 
piecemeal from files scattered around the repository, and the 
repository is subsequently updated from such a sandbox.  What happens 
is that the set of files affected by the locks is much greater than 
necessary.  This is the very problem that tools such as meta-cvs and 
dcvs must solve when mapping RCS files to their counterparts in the 
sandbox.  Those who have read info-cvs for any length of time know that 
CVS' inability to rename a file is one of my hot buttons.  Locking 
using a method like the one I  propose makes implementing such a 
feature a lot easier.  Moving the repository to a relational database 
does, too, but I assume that such a move would be shot down by much of 
the user community.