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

Re: Making fsfs generate unique transaction names

From: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-06-14 00:50:37 CEST

Blair Zajac <blair@orcaware.com> writes:
> I'm making a svn filesystem network aware using Ice RPC and one of the
> things I'm running into is that FSFS transactions are not unique. BDB
> seems to generate transaction names via a sequence, so this isn't an
> issue.
> I have the ability for a client to begin a transaction remotely and
> then refer to that transaction to do work. In FSFS, if a client
> begins a transaction, gives the transaction name to another process,
> which then closes it, and a third process begins a new transaction
> based on the same revision, then it will get the same transaction name
> and the owner of the original transaction will be operating inside a
> different transaction and will be able to abort the transaction, which
> it should not be able to do.
> So I'd like to make the transaction names unique, using something like
> "%s-%05ds-%s-%05d" % (apr_gethostname(),
> apr_uid_current(),
> apr_time_now(),
> i)
> where i is incremented until it finds a non-existent directory name.
> The current transaction name is based off the revision number, is this
> necessary? Should we keep it? Does changing the transaction name
> have any other impact?

+1 on making transaction names unique -- in fact, maybe we
should take this opportunity to add that as an API promise too. We
might well add features to Subversion someday that involve the use of
long-lived transactions.

I don't see any reason why the transaction number needs to be based
off the revision number, assuming it has another way of associating
itself with its base revision (which it does, right?).


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 14 00:50:47 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.