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

Re: [PATCH] [merge-tracking] in memory mergeinfo hash for fs_fs

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2006-08-31 12:47:07 CEST

On Thu, Aug 31, 2006 at 11:32:21AM +0530, Kamesh Jayachandran wrote:
> Daniel Berlin wrote:
> >It's still not going to work.
> >Again, you can do the following, and it is supposed to work:
> >
> >Start an svn transaction in one process
> >Close the transaction
> >
> >Start a new svn process
> >Reopen the old transaction
> >Commit it
> >
> >If you store it in memory only, this will not work.
> Can you give a usecase where this is needed?

Dan just did. Our API explicitly allows the user to do the above,
and we need to support it, unfortunately. ('Unfortunately', because
in my opinion this isn't something that's particularly sensible to do,
and it complicates the filesystem code).

> I remember 'svnadmin lstxns/rmtxns' needs this disk based storage.

No, you've got it the wrong way round :-). We need lstxns/rmtxns
_because_ we support persistent uncommitted transactions.

I can't see any reason offhand that you couldn't choose to persist
the hash to disk only at transaction close time, though. Mind you,
that does get into the discussion about the concurrent access that's
allowed for transactions, though, which we've never really documented.
(For example, is it valid to open a transaction that's currently opened
by another thread/process? It's be good if we could assert that the
answer was 'no', but I'm not sure whether we can do that).


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 31 12:47:48 2006

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.