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

Re: [merge-tracking]Why we need PATH_TXN_MERGEINFO in merge-tracking?

From: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2006-09-13 13:59:51 CEST

> If above snip is the purpose of this implementation, I have the following
> thoughts,
> a)Why to have it has a disk-based storage?
> I am against it for the following reasons
> * As this(svn:mergeinfo) data is not meant for sharing with other
> tools like 'svnadmin' and
> 'svnlook', this filebased storage is a wrong choice.
> - I have a in-memory equivalent patch for the same.
> * It is a joke to keep creating new hash in memory and dump to file
> within the
> same program execution context for each path having 'svn:mergeinfo'.
> - I have another patch which does the same indexing from
> 'write_final_rev' without caching at all.
> * It is a data redundancy issue.

We have been through this before. Different processes are allowed to
reopen the transaction, and have no shared state between them. Thus,
it must be stored on disk.
I hate it as well, and I would not have implemented it this way if it
was not required by our current API.

As i've also explained before, it was at one point, only stored in
memory. But we can't do this and still support the API of reopening
transactions betweens processes.

You can argue that we should only keep this stuff in memory till you
are blue in the face. I don't disagree, and as i've said, this was
the way it was originally done. However, it is simply not legal in
the face of what our current API allows. This will not change until
2.0, because of our API guarantees, so I highly suggest we just move


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 13 14:00:21 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.