info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Locking (was Re: CVS Transaction)


From: Russ Sherk
Subject: Re: Locking (was Re: CVS Transaction)
Date: Thu, 8 Sep 2005 15:48:01 -0400

On 9/8/05, Derek Price <address@hidden> 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.

Is the OP asking for a locking transaction or a shortcut for:
----------------------
cvs co sandbox
cvs tag -b trans-br sandbox
cvs up -rtrans-br sandbox
<edit>
test : cvs ci sandbox?rm -rf sandbox
[test :cvs up -A sandbox; cvs up -jtrans-br sandbox]
----------------------
in which case it is not absolutely necessary to lock and writeability
is not compromised any more than usual.

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

Yes.  How about:
start transaction <generate commitid/transid (1234)>
<edit>
<commit> - commitid=1234
<edit>
<commit> - commitid=1234
end transaction (clear commitid)

instead of 1 id per 'cvs ci'

and:
start transaction <user specified commt/trans-id (5678)>
<edit>
<commit> - commitid=5678
end transaction

instead of always generating an id.  (this one is tougher because of
possible id confilcts).

Regards,

--Russ

> 
> 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>
> 
> 
> 
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/info-cvs
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]