[evs] Current Status

Tony Hoyle tony.hoyle at march-hare.com
Sat Feb 10 15:01:05 GMT 2007

Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.

Glen Starrett wrote:
> That sounds excellent.  Will this bring transacted operations into play? 
>  E.g. at the lowest level the concept of "atomic commits" and at higher 
> levels commands that could be batched together (like commit + tag + 
> permissions)?  I can't come up with a rational use case for the latter 
> ATM, but it sure sounds cool.  :)
In theory you could batch commands.. that's just a matter of where the 
database commits are.

> That assumes the database supports transactions, of course.  I would 
> think it wouldn't be worthwhile to try and add transaction capability to 
> a DB that doesn't understand them.
I'm not sure it would be worth supporting databases that didn't have 
transactions.. we kinda rely on them to handle the rollback if anything 
goes wrong.  Even sqlite has transactions...

One question:  Would anyone be particularly upset if the generated RCS 
revision numbers weren't sequential?

eg. instead of 1.1, 1.2, 1.3 you end up with 1.12, 1.47, 1.384 etc.  it 
seems to me the easiest way to do the translation - I aim to produce 
them in such a way that something like cvsgraph could make sense of 
them, so can be interpreted in the rcs way (revision 274 of 
branch 32 based on 1.24).  Keeping sequential numbers is possible but it 
makes the calculation harder (since the cvs layer needs to be able to 
talk in terms of rcs revision numbers I want to make that as fast as 


More information about the evs mailing list