Re: Changing the "native" newline mode
On Sun, Feb 14, 2010 at 2:34 AM, Glenn Maynard wrote:
> Based on looking through [1] some more, it looks like "cp -a wc1 wc2"
> and renaming working copies should work fine, since the database is
> inside the working copy, and will just get copied along with the rest.
In SVN 1.7 there will be a single .svn folder at the root of a working
copy. Beyond 1.7 there are plans to make this configurable so that
you could have it in ~/.subversion and shared across all your working
copies. Of course the default will be the same as it will be in 1.7.
> Hopefully there'll still be a way to slice out a piece of a repository
> ("mv wc1/trunk .; rm -rf wc1"), which wouldn't work if it's dependent
> on a global db at the top.
There has been talk of adding a svn detach command to do this. Not
sure if it will be done as part of 1.7. AFAIK, the plan is to add it
later.
> I have a few gigs of ~5 meg files in Subversion, and the idea of
> storing large blocks of data in SQLite is a bit scary; I don't think
> it's designed for blobs that size. Anything that lumps files together
> like this is effectively subjected to two layers of fragmentation
> instead of one (filesystem + db).
There has never been any plan or discussion to store the pristine
files in SQLite. As you point out, it is not well suited for that and
would work poorly. SQLite is being used to store the SVN metadata and
properties which are arguably just stored in a custom DB today. When
the WC data is centralized the current code that has to read all the
metadata, parse it and write it back out would be less efficient than
using a database and just being update/insert rows as needed. Plus we
got some benefits from being able to use SQL indexes.
The storage format for the pristine files will still be files but it
is being changed to be based on the SHA-1 hash for the files. I'd
imagine the structure will be sharded based on the first two
characters of the hash. This will bring several benefits:
1) On case insensitive file systems like Windows and OSX it will allow
files to be renamed only by case. Today that fails because of the way
the pristine copy is stored. Once it is a SHA-1, it will not matter.
2) Space savings. When you have files in a working copy with the same
hash, there will only be a single pristine copy stored. This will
likely be a minor benefit in 1.7, but imagine when you can have all
your working copies centralized in a single location. If you have
multiple copies of trunk checked out, or even multiple branches, it is
likely there would be a lot of sharing of pristine copies and would
save a significant amount of disk space.
3) Performance. This will be a future benefit. But again, imagine
you have a single centralized working copy area. When you do a
checkout we can enhance the client/server protocol so that the when
the server returns the list of items for the client to fetch it also
includes the SHA-1. Now the client can be made smart enough to only
fetch the items it does not already have. So imagine you have trunk
checked out and you want to checkout a branch. Maybe 90% of the files
would already be on your disk and the client could just fetch the
other 10% and construct the working copy from what it already has
available.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Changing the "native" newline mode
On Sun, Feb 14, 2010 at 9:45 AM, Mark Phippard wrote:
> copy. Beyond 1.7 there are plans to make this configurable so that
> you could have it in ~/.subversion and shared across all your working
> copies. Of course the default will be the same as it will be in 1.7.
That sound brittle. Users would need to inform Subversion about
deleted working copies (to drop references to text-bases, etc.), which
would inevitably not always happen, leading to accumulating cruft.
It'd also break when the shared path can't be found (eg. shared NFS
mounts, moving/renaming home directories). (I assume the actual
working copies would be matched to its metadata on a UUID basis, so at
least moving and renaming the working copies themselves would be
unaffected.)
>> Hopefully there'll still be a way to slice out a piece of a repository
>> ("mv wc1/trunk .; rm -rf wc1"), which wouldn't work if it's dependent
>> on a global db at the top.
>
> There has been talk of adding a svn detach command to do this. Not
> sure if it will be done as part of 1.7. AFAIK, the plan is to add it
> later.
Hmm. It's very unusual for Subversion upgrades to take away
functionality and say "we'll fix this later".
> The storage format for the pristine files will still be files but it
> is being changed to be based on the SHA-1 hash for the files. I'd
> imagine the structure will be sharded based on the first two
> characters of the hash. This will bring several benefits:
I don't see anything wrong with this, but the "space savings" and
"performance" benefits hinge on the shared store. I suspect the real
benefits are infrastructural, rather than user-visible.
--
Glenn Maynard
Re: Python & RA
Роман Донченко писал в своём письме Tue, 19 Jan 2010
21:08:04 +0300:
Daniel Eggert писал в своём письме Tue, 19 Jan
2010 20:12:50 +0300:
On Jan 19, 2010, at 7:25 , Роман Донченко wrote:
On Mon, 2010-01-18 at 20:12 -0600, Daniel Eggert wrote:
The config argument isn't passed to the C API correctly ATM... you can
use a NULL config if that's enough for your needs:
svn.ra.open2("http://svn.example.com/svn";, c, None)
Roman (who didn't get the original mail because of the Gmane mishap).
Thanks. That works. Should I file a bug about that not working?
Eh, probably not. I've entered it into my todo list and will probably
get around to it soon.
This has now been fixed in trunk. It took some uneasy changes to the
infrastructure, though, so I won't backport this to 1.6.x. Note that the
common cases of passing None or the result of core.svn_config_get_config
do work in 1.6.
Roman.
Re: Python & RA
Den Feb 14, 2010 kl. 15:18 skrev Роман Донченко
:
Роман Донченко писал в
своём письме Tue, 19 Jan 2010 21:08:04 +0300:
Daniel Eggert писал в своём
письме Tue, 19 Jan 2010 20:12:50 +0300:
On Jan 19, 2010, at 7:25 , Роман Донченко wrote:
On Mon, 2010-01-18 at 20:12 -0600, Daniel Eggert wrote:
The config argument isn't passed to the C API correctly ATM...
you can use a NULL config if that's enough for your needs:
svn.ra.open2("http://svn.example.com/svn";, c, None)
Roman (who didn't get the original mail because of the Gmane
mishap).
Thanks. That works. Should I file a bug about that not working?
Eh, probably not. I've entered it into my todo list and will
probably get around to it soon.
This has now been fixed in trunk. It took some uneasy changes to the
infrastructure, though, so I won't backport this to 1.6.x. Note that
the common cases of passing None or the result of
core.svn_config_get_config do work in 1.6.
Roman.
Great. Thanks for the update.
/Daniel
