[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

--pre-1.X-compatible and fsfs transaction counter

From: Blair Zajac <blair_at_orcaware.com>
Date: 2007-07-27 19:11:59 CEST

I'm working on adding a new transaction-current file to the fsfs backend to
increment transaction ids.

Should this new transaction id generation code be used all the time and replace
the old transaction id generation code, or should we keep the old code for
repositories created with --pre-1.4-compatible or --pre-1.5-compatible or were
created with 1.4 or earlier?

I think that even if the new transaction id generation code was always used in
svn 1.5 or greater and a repository was created with --pre-1.4-compatible or
--pre-1.5-compatible and a commit was done in it with a 1.4 or earlier version
of svn, then there wouldn't be any issues. The ids from 1.4 and older have a
different format (<rev>-<uniquifier>) than the new ids (<base36-sequence-number>).

However, maybe we should use the new code only in 1.5 repositories. If somebody
does a hotcopy of a repository using 1.4 or earlier, the transaction-current
will not be copied and when 1.5 touches it, it'll recreate the
transaction-current file starting at 0, which would reuse transaction ids. It
sounds like fsfs doesn't handle reusing transaction ids for transactions based
off different revisions.

It also may be safer to always put the revision number into the new 1.5
transaction ids (<rev>-<base36-sequence-number>), just in case there's something
else that hasn't been considered, as the current code works fine when this is done.

Regards,
Blair

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 27 19:10:46 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.