On 9/8/05, Derek Price <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]> > > > > > _______________________________________________ > Info-cvs mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/info-cvs > _______________________________________________ Info-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/info-cvs
