* www/project_faq.html: Bring the FAQ towards well-formed XHTML.
Index: project_faq.html
===================================================================
--- project_faq.html (revision 9461)
+++ project_faq.html (working copy)
@@ -401,13 +415,14 @@
<![CDATA[-----------------------------------------------------------]]>
<h3><a name="co-svn">How do I check out the Subversion code?</a></h3>
-<p>Use the subversion client:
+<p>Use the subversion client:</p>
<pre>
$ svn co http://svn.collab.net/repos/svn/trunk subversion
</pre>
<p>
That will check out a copy of the Subversion source tree into a
directory named subversion on your local machine.
+</p>
<![CDATA[-----------------------------------------------------------]]>
@@ -614,7 +629,7 @@
<p>It depends upon the projects involved. If the projects are
related, and are likely to share data, then it's best to create one
-repository with several subdirectories like this:
+repository with several subdirectories like this:</p>
<pre>
$ svnadmin create /repo/svn
$ svn mkdir file:///repo/svn/projA
@@ -622,9 +637,9 @@
$ svn mkdir file:///repo/svn/projC
</pre>
-If the projects are completely unrelated, and not likely to share data
+<p>If the projects are completely unrelated, and not likely to share data
between them, then it's probably best to create separate and unrelated
-repositories.
+repositories.</p>
<pre>
$ mkdir /repo/svn
$ svnadmin create /repo/svn/projA
@@ -633,7 +648,7 @@
</pre>
<p>
The difference between these two approaches is this (as explained by
-Ben Collins-Sussman <sussman@collab.net>):
+Ben Collins-Sussman <sussman@collab.net>):</p>
<ul>
<li>
@@ -672,35 +687,35 @@
<p>If you don't care about retaining all the history of one of the
repositories, you can just create a new directory under one project's
-repository, then import the other.
+repository, then import the other.</p>
<p>If you care about retaining the history of both, then you can use
'svnadmin dump' to dump one repository, and 'svnadmin load' to load it into
the other repository. The revision numbers will be off, but you'll
-still have the history.
+still have the history.</p>
<p>Peter Davis <peter@pdavis.cx> also explains a method using svn's
-equivalent to CVS modules:
+equivalent to CVS modules:</p>
<p><blockquote>
<p>As long as the merging takes place in separate directory
- trees, you can use svn's version of CVS modules.
+ trees, you can use svn's version of CVS modules.</p>
<p>Set the <em>svn:externals</em> property on a directory to checkout
directories from other repositories whenever the original
directory is checked out. The repository remains separate,
but in the working copy it appears that they have been merged.
If you commit to the imported directory, it will affect the
- external repository.
+ external repository.</p>
<p>The merge isn't completely clean: the import only affects
working copies, so you won't be able to use a URL in the first
repository to access modules imported from the second. They
- remain separate URLs.
+ remain separate URLs.</p>
</blockquote>
+</p>
-
<![CDATA[=========================================================]]>
<h3><a name="nfs">Should I store my repository on a NFS server?</a></h3>
@@ -830,7 +845,7 @@
<h3><a name="patch">How do I submit a patch for Subversion?</a></h3>
-<p>FIRST, read the HACKING document.
+<p>FIRST, read the HACKING document.</p>
<p>Once you've digested that, send a mail to the dev list with the
word [PATCH] and a one-line description in the subject, and include
@@ -838,7 +853,7 @@
totally). Then a committer will pick it up, apply it (making any
formatting or content changes necessary), and check it in.
-<p>The basic process looks like this:
+<p>The basic process looks like this:</p>
<pre>
<blockquote>
$ svn co http://svn.collab.net/repos/svn/trunk subversion
@@ -852,11 +867,11 @@
</blockquote>
</pre>
-Of course, the email you send should contain a nice long
+<p>Of course, the email you send should contain a nice long
explanation about what the patch does, as per the
<a href="http://svn.collab.net/repos/svn/trunk/HACKING">HACKING</a>
document, but you already know that, since you read and completely
-understood it <em>before</em> actually hacking the code, right? :)
+understood it <em>before</em> actually hacking the code, right? :)</p>
<![CDATA[=========================================================]]>
@@ -1032,10 +1046,12 @@
<p>
Then for each working copy, change to the relevant directory and do:
+</p>
<pre>
svn update *
svn update
</pre>
+<p>
The first update will remove <tt>file.java</tt> from your working copy,
the second update will add <tt>File.java</tt>, leaving you with a
correct working copy.
@@ -1437,7 +1453,7 @@
server?</a></h3>
<p>Use Ethereal to eavesdrop
-on the conversation:
+on the conversation:</p>
<!-- TODO: Make these instructions less specific to ra_dav. -->
<ol>
@@ -1454,7 +1470,7 @@
client's HTTP conversion.</li>
</ol>
-The above instructions are specific to the graphical version of
+<p>The above instructions are specific to the graphical version of
Ethereal, and may not apply to the commandline version (whose binary
is usually named tethereal).</p>
--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 23 17:49:35 2004