On Tuesday 04 November 2003 17:10, C. Michael Pilato wrote:
> John Szakmeister <john@szakmeister.net> writes:
> > If I understand how this works correctly, this 'svnadmin tunefs'
> > wouldn't interfere with normal repository operation, correct? If
> > that's true then I'd say it's not a lot to ask to run this in the
> > post-commit process or as a cron-job. However, if it does
> > interfere, I would -1 this. I would have to agree with Jack in that
> > this should be site-friendly and 'global development' friendly.
>
> What do you mean by interfere? Berkeley DB locking struggles? Node
> revisions getting deltified by multiple processes at the same time?
I should've been more clear about that. I mean 'interfere' as in it raises
the current bar for potential conflicts with locking, deltification by
multiple processes, and for potential errors/problems that the user has to
deal with. I'd hate to see anything that would push back more problems to a
user. I.e., an increased potential for typical repository operations to
fail.
> The proposal is very simple. Today we have a routine which runs over
> the items changed in a particular revision and deltifies the
> predecessors of those items. 'svnadmin tunefs' would simply relocate
> calls to that code from the commit process to an external program.
> All the ways in which multiple instances of the deltification code
> could knock heads with each other in the current scenario would still
> be present in the new one -- but not additional ones, and as noted,
> the individual user experience is greatly enhanced.
I wasn't sure how you were proposing this, and from some of the communication,
I was frightened that we'd essentially have to take the repository offline in
order to run this deltification process. However, if the current set up can
handle it, and the only difference is that we have to call 'svnadmin tunefs'
to do the deltification, then I'm alright with that (not that my opinion
counts for anything :-), especially if it enhances the user experience.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 4 23:26:47 2003