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 1.24.32.274 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 possible). Tony