"Kirby C. Bohling" <kbohling@birddog.com> writes:
> do something that allows reasonable recovery expectations, document it,
> and allow the user to modify the parameters to get exactly what they
> want. Create a svnadmin shrink/scrub/etc... rather then a script, and
> explain what it is doing in the man page. Explain that it cleans up
> after the database and you DO NOT lose revision history. People read
> man pages, they ignore scripts in the tools directory in my experience
> (well I do *grin*).
>
> Take the code that was the body the the thread and stick it in svnadmin,
> make it take several options including compress or not, maybe a
> percentage of repository size that log files can be, and how old the
> oldest log to keep around is. If that is acceptable, tell me I'll
> submit a patch for it. A user can fire and forget with that command
> using cron, or put it in post commit hook as suggested on the list.
-1 on putting it in svnadmin. I understand your reasoning, but you
can refer to a script from the man page as easily as you can refer to
built-in functionality, if that's the issue.
This is a highly scripty task. It's lots of shell commands,
basically. Putting it in svnadmin will a) take much more time, b) be
much harder to maintain, and c) be more likely to be buggy, than if we
do it in a script.
`svnadmin' is Subversion-specific, in a way that log file archival is
not. Berkeley DB maintenance is roughly the same procedure whatever
the contents of the DB, and this cleanup routine need know nothing
about Subversion's filesystem semantics to do its job.
If it's a script, would you still be interested in contributing it?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:04 2006