> 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
on.
--Dan
---------------------------------------------------------------------
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