Malcolm Rowe writes:
> So I've a much simpler way to fix this problem: allow the repository
> administrator to specify an area of the _local_ filesystem to use for
> marshalling transaction data. Only the proto-rev and revprops files
> actually need to be stored on the NAS: the others can just remain on the
> local disk until it's time to do the final commit.
>
> (So we might be writing to, say, /var/tmp/myrepo/1-1.txn/node._1.0 and
> /nfs/repos/myrepo/db/transactions/1-1.txn/rev).
>
> But again, this isn't suitable for everyone. And in this case, there's
> not even a reasonable default location for the local storage.
Wouldn't what svn_io_temp_dir give us a reasonable place?
>
But this means that the transaction is actually incomplete as stored
in the repository, or am I missing something?
In tha tcase, we definitely need a switch to at least turn it on, because it
can be quite dangerous.
>
> So, here's the plan:
>
> - Store those options into a new db/config file, probably in our normal
> config format. If neither option is used, don't create a file.
> - Bump the fs format number if the db/config file is created, because
> older clients won't know to read it.
> - Don't offer any way to change the config manually after creation save
> for a dump/load cycle, at least not initially.
>
I think a db/config is fine in general, but not for values that can't just
be tweaked. I think values that only svnadmin (or similar) should chagne
should be stored in some internal file and we could use db/config for
things users could actually tweak (like a location for temporary files).
So I don't think sharding, which actually affects the format of the repository,
should be stored in a config file.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 5 11:56:56 2007