I wasn't feeling particularily lyrical when doing this, so feel free
to come up with better expressions.
Oh and, is the following sentence still true?
The problem is that BerkeleyDB 4.2 is newer than the latest released
version of apr-util, so apr-util doesn't know how to detect it.
I debated for a moment or two whether to mention mention that future
development versions of Subversion may again require dump & load
cycles on upgrading, but decided that it doesn't need to be explictly
said in the FAQ considering its target audience.
If no-one has any complaints or improvements, I can toss this
in. Though I have no idea how to update the actual web-pages after
that, if such a thing is still necessary.
-- Naked
Log message:
Some cleanups for project FAQ.
* www/project_faq.html (dumpload): We aren't pre-1.0 anymore, so
advise it is for old repositories.
* www/project_faq.html (wedged-wc): Control-C does not cause a wedged
working copy anymore, so say so.
Patch:
Index: www/project_faq.html
===================================================================
--- www/project_faq.html (revision 8976)
+++ www/project_faq.html (working copy)
@@ -886,12 +886,12 @@
<h3><a name="dumpload">What is this "dump/load cycle" people
sometimes talk about when upgrading a Subversion server?</a></h3>
-<p>Subversion's repository database schema changes occasionally during
-development. We try to keep such changes to a minimum, but Subversion
-<i>is</i> pre-1.0 software, and we want to ship 1.0 with the best
-schema we can. If a schema change happens between Subversion releases
-X and Y, then repository administrators upgrading to Y must do the
-following: </p>
+<p>Subversion's repository database schema has changed occasionally
+during development. Old repositories, created with a pre-1.0
+development version of Subversion, may require the following operation
+when upgrading. If a schema change happens between Subversion
+releases X and Y, then repository administrators upgrading to Y must
+do the following: </p>
<p>
<ol>
@@ -1097,12 +1097,13 @@
Your working copy is not corrupt, nor is your data lost. Subversion's
working copy is journaling system, meaning that it logs everything it
is about to do before it does so. If the svn client program is
-interrupted (Control-C, or segfault), then one or more lockfiles are
-left behind, along with logfiles describing unfinished business.
-(The`svn status' command will show an 'L' next to locked directories.)
-Any other process that attempts to access the working copy will fail
-when it sees the locks. To awaken your working copy, you need to tell
-the svn client to finish the work. Simply run:</p>
+interrupted violently (segfault or killed, not with Control-C), then
+one or more lockfiles are left behind, along with logfiles describing
+unfinished business. (The`svn status' command will show an 'L' next
+to locked directories.) Any other process that attempts to access the
+working copy will fail when it sees the locks. To awaken your working
+copy, you need to tell the svn client to finish the work. Simply
+run:</p>
<pre>
svn cleanup working-copy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 12 02:20:06 2004