You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <da...@elego.de> on 2011/07/07 22:50:22 UTC
Re: svn commit: r1144028 -
/subversion/branches/revprop-packing/subversion/libsvn_fs_fs/fs_fs.c
Hmm. For wc we have upgrade tests using tarred old working copies.
Perhaps we should do the same for svnadmin/fsfs?
% grep upgrade svnadmin_tests.py | wc -l
0
hwright@apache.org wrote on Thu, Jul 07, 2011 at 20:47:01 -0000:
> Author: hwright
> Date: Thu Jul 7 20:47:01 2011
> New Revision: 1144028
>
> URL: http://svn.apache.org/viewvc?rev=1144028&view=rev
> Log:
> On the revprop-packing branch:
> Copy our packed revprops as part of hotcopy. Number of test failures is down
> to 39.
>
> * subversion/libsvn_fs_fs/fs_fs.c
> (svn_fs_fs__hotcopy): Copy the packed revprop shards just as we do revision
> shards.
>
> Modified:
> subversion/branches/revprop-packing/subversion/libsvn_fs_fs/fs_fs.c
>
> Modified: subversion/branches/revprop-packing/subversion/libsvn_fs_fs/fs_fs.c
> URL: http://svn.apache.org/viewvc/subversion/branches/revprop-packing/subversion/libsvn_fs_fs/fs_fs.c?rev=1144028&r1=1144027&r2=1144028&view=diff
> ==============================================================================
> --- subversion/branches/revprop-packing/subversion/libsvn_fs_fs/fs_fs.c (original)
> +++ subversion/branches/revprop-packing/subversion/libsvn_fs_fs/fs_fs.c Thu Jul 7 20:47:01 2011
> @@ -1677,17 +1677,26 @@ svn_fs_fs__hotcopy(const char *src_path,
>
> SVN_ERR(svn_io_make_dir_recursively(dst_subdir, pool));
>
> - /* Copy the packed revprop db. */
> - if (format >= SVN_FS_FS__MIN_PACKED_REVPROP_FORMAT)
> + /* First, copy packed shards. */
> + for (rev = 0; rev < min_unpacked_revprop; rev += max_files_per_dir)
> {
> - const char *src_file = svn_dirent_join(src_subdir, PATH_REVPROPS_DB,
> - pool);
> - const char *dst_file = svn_dirent_join(dst_subdir, PATH_REVPROPS_DB,
> - pool);
> - SVN_ERR(svn_sqlite__hotcopy(src_file, dst_file, pool));
> + const char *packed_shard = apr_psprintf(iterpool, "%ld.pack",
> + rev / max_files_per_dir);
> + const char *src_subdir_packed_shard;
> + src_subdir_packed_shard = svn_dirent_join(src_subdir, packed_shard,
> + iterpool);
> +
> + SVN_ERR(svn_io_copy_dir_recursively(src_subdir_packed_shard,
> + dst_subdir, packed_shard,
> + TRUE /* copy_perms */,
> + NULL /* cancel_func */, NULL,
> + iterpool));
> + svn_pool_clear(iterpool);
> }
>
> - for (rev = min_unpacked_revprop; rev <= youngest; rev++)
> + /* Then, copy non-packed shards. */
> + SVN_ERR_ASSERT(rev == min_unpacked_revprop);
> + for (; rev <= youngest; rev++)
> {
> const char *src_subdir_shard = src_subdir,
> *dst_subdir_shard = dst_subdir;
>
>
Re: svn commit: r1144028 - /subversion/branches/revprop-packing/subversion/libsvn_fs_fs/fs_fs.c
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 07/07/2011 04:59 PM, Daniel Shahaf wrote:
> Then why does 'svnadmin upgrade' say
>
> % $svnadmin upgrade r3
> Repository lock acquired.
> Please wait; upgrading the repository may take some time...
Heheh. Because that message was copy-n-pasted from the one used for
'svnadmin recover'. :-)
I implemented 'svnadmin upgrade' in response to the fact that the project
decided at some point to stop auto-upgrading filesystems when first touched
by a new version of Subversion. As such, the point of 'svnadmin upgrade'
was merely to do the very same steps that the auto-upgrade would have done.
We would never undertake any non-trivial morphing of *repository data* in
an automated, often-unattended fashion! And we already have a sanctioned,
proven mechanism for doing such non-trivial, data-munging upgrades
(dump/load). So 'svnadmin upgrade' merely acts as a trigger for the
no-longer-automatic trivial upgrades required merely to enable
format-specific features.
(If folks wish to explore expansion of the feature into the non-trivial
upgrade space, that's certainly something the project can discuss. I'm
merely speaking to the history of the subcommand as it sits today.)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn commit: r1144028 -
/subversion/branches/revprop-packing/subversion/libsvn_fs_fs/fs_fs.c
Posted by Daniel Shahaf <da...@elego.de>.
C. Michael Pilato wrote on Thu, Jul 07, 2011 at 16:54:46 -0400:
> On 07/07/2011 04:50 PM, Daniel Shahaf wrote:
> > Hmm. For wc we have upgrade tests using tarred old working copies.
> > Perhaps we should do the same for svnadmin/fsfs?
> >
> > % grep upgrade svnadmin_tests.py | wc -l
> > 0
>
> We haven't tested upgrades of filesystems in the past because we thus far
> haven't allowed 'svnadmin upgrade' to do anything substantial. Typically,
> it just plops a new integer into the 'format' file. There was some minor
We don't test 'svnadmin pack' either.
> file reorg in the FSFS side a while ago, but again, nothing really major.
> And that's intentional: we want upgrade to be a constant-time operation,
Then why does 'svnadmin upgrade' say
% $svnadmin upgrade r3
Repository lock acquired.
Please wait; upgrading the repository may take some time...
?
> leaving more costly upgrades to the likes of a parallel dump/load.
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
Re: svn commit: r1144028 -
/subversion/branches/revprop-packing/subversion/libsvn_fs_fs/fs_fs.c
Posted by Daniel Shahaf <da...@elego.de>.
C. Michael Pilato wrote on Thu, Jul 07, 2011 at 16:54:46 -0400:
> On 07/07/2011 04:50 PM, Daniel Shahaf wrote:
> > Hmm. For wc we have upgrade tests using tarred old working copies.
> > Perhaps we should do the same for svnadmin/fsfs?
> >
> > % grep upgrade svnadmin_tests.py | wc -l
> > 0
>
> We haven't tested upgrades of filesystems in the past because we thus far
> haven't allowed 'svnadmin upgrade' to do anything substantial. Typically,
> it just plops a new integer into the 'format' file. There was some minor
We don't test 'svnadmin pack' either.
> file reorg in the FSFS side a while ago, but again, nothing really major.
> And that's intentional: we want upgrade to be a constant-time operation,
Then why does 'svnadmin upgrade' say
% $svnadmin upgrade r3
Repository lock acquired.
Please wait; upgrading the repository may take some time...
?
> leaving more costly upgrades to the likes of a parallel dump/load.
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
Re: svn commit: r1144028 - /subversion/branches/revprop-packing/subversion/libsvn_fs_fs/fs_fs.c
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 07/07/2011 04:50 PM, Daniel Shahaf wrote:
> Hmm. For wc we have upgrade tests using tarred old working copies.
> Perhaps we should do the same for svnadmin/fsfs?
>
> % grep upgrade svnadmin_tests.py | wc -l
> 0
We haven't tested upgrades of filesystems in the past because we thus far
haven't allowed 'svnadmin upgrade' to do anything substantial. Typically,
it just plops a new integer into the 'format' file. There was some minor
file reorg in the FSFS side a while ago, but again, nothing really major.
And that's intentional: we want upgrade to be a constant-time operation,
leaving more costly upgrades to the likes of a parallel dump/load.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn commit: r1144028 - /subversion/branches/revprop-packing/subversion/libsvn_fs_fs/fs_fs.c
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 07/07/2011 04:50 PM, Daniel Shahaf wrote:
> Hmm. For wc we have upgrade tests using tarred old working copies.
> Perhaps we should do the same for svnadmin/fsfs?
>
> % grep upgrade svnadmin_tests.py | wc -l
> 0
We haven't tested upgrades of filesystems in the past because we thus far
haven't allowed 'svnadmin upgrade' to do anything substantial. Typically,
it just plops a new integer into the 'format' file. There was some minor
file reorg in the FSFS side a while ago, but again, nothing really major.
And that's intentional: we want upgrade to be a constant-time operation,
leaving more costly upgrades to the likes of a parallel dump/load.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand