From: Chris Frost <chris@fr...> - 2011-11-07 06:13:29
Starting with Subversion 1.7, existing versions of scord have no effect on
a working copy. That is, scord no longer reduces the disk space used by a
Subversion working copy.
With the Subversion 1.7 release, Subversion moved to a new working copy
metadata storage format ("wc-ng"), which changed how a Subversion client
stores the pristine (née text-base) copies of checked-out files. Because
scord uses knowledge of this storage format, running Subversion on top of
scord no longer affects Subversion working copies.
I would like to do the same for Subversion 1.7+ working copies as for
those in earlier versions of Subversion, but I don't have a technical
plan of attack or a timeline.
FWIW, the old metadata format stored files using this path style:
Working file: /project/subdir/foo
Text-base file: /project/subdir/.svn/text-base/foo.svn-base
The new metadata format is, roughly:
Pristine file: /project/.svn/pristine/<SHA-1 hash of the contents of foo>
The first issue I see for scord is finding the existing working file(s)
to share when the pristine file is created: scord would know only the
content of the pristine file; it would not have the working file's path.
Perhaps scord could find the working file by reading the new working copy
format's SQLite database, or by maintaining a scord hash->path map, or by
scanning new files at scord start. Maintaining consistency in the face of
process and system crashes will be an issue in some/all of these approaches.
Or, perhaps a non-file-system approach would work better with the new schema.
FWIW, the Subversion 1.7 announcement includes a description of the wc changes:
and the URLs for the Subversion working copy design docs and source are:
Get latest updates about Open Source Projects, Conferences and News.