comments, please: rev 7706 - trunk/subversion/libsvn_repos

My concern around this is if the deltification process holds locks for a
"long time", then its lower priority could cause the locks to be held
longer than necessary, which then delays the processes we actually want to
operate "fast". Of course, the OS should "bump" the priority of the
deltify if everybody is waiting for its locks.

Any ways... it seems like it should be fine, but wanted to ask the list
whether anybody can see a problem here.

Cheers,
-g

On Tue, Nov 11, 2003 at 05:45:35PM -0600, gstein@tigris.org wrote:
>....
> Log:
> Slight tweaks to the recommendation of the deltify process.
>
> * libsvn_repos/repos.c:
> (create_hooks): for the 'svnadmin deltify', put it into the background,
> and drop its priority a little bit. we don't want it to compete with
> the primary operation of the server.
>
>
> Modified: trunk/subversion/libsvn_repos/repos.c
> ==============================================================================
> --- trunk/subversion/libsvn_repos/repos.c (original)
> +++ trunk/subversion/libsvn_repos/repos.c Tue Nov 11 17:45:34 2003
> @@ -639,7 +639,7 @@
> APR_EOL_STR
> "# Deltify predecessors of things changed in this revision."
> APR_EOL_STR
> - "svnadmin deltify \"$REPOS\" -r \"$REV\""
> + "nice -2 svnadmin deltify \"$REPOS\" -r \"$REV\" &"
> APR_EOL_STR
> APR_EOL_STR
> "commit-email.pl \"$REPOS\" \"$REV\" commit-watchers@example.org"

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org