remove pesky file...

This commit is contained in:
gferg 2001-09-13 18:29:19 +00:00
parent 174a9176f9
commit 987891f720
1 changed files with 0 additions and 256 deletions

View File

@ -1,256 +0,0 @@
<section id="cvs">
<title> CVS </title>
<para>
The LDP is providing CVS access to authors. There are a few
good reasons for this:
</para>
<orderedlist inheritnum="ignore" continuation="restarts">
<listitem>
<para> CVS will keep an off-site backup of your documents. In
the event that you hand over a document to another author,
they can just retrieve the document from CVS and continue
on. In the event you need to go back to a previous version of
a document, you can retrieve it as well. </para>
</listitem>
<listitem>
<para> It's great if you have many people working on the same
document. You can have CVS tell you what changes were made
while you were editing your copy by another author, and
integrate those changes in. </para>
</listitem>
<listitem>
<para> Keeps a log of what changes were made. These logs (and
a date stamp) can be placed automatically inside the document
when you use some special tags that get processed before the
SGML processor. </para>
</listitem>
<listitem>
<para> Can provide for a way for a program to automatically
update the LDP web site with new documentation as it's written
and submitted. This is not in place yet, but is a potential
goal. Currently, CVS updates signal the HOWTO coordinator to
update the LDP web page, meaning that if you use CVS, you're not
required to e-mail your SGML code. </para>
</listitem>
</orderedlist>
<para> If you're completely new to CVS, there are a few web pages
you may want to look at which can help you out: </para>
<itemizedlist>
<listitem>
<para> <ulink
url="http://www.sourcegear.com/CVS/Docs/blandy">http://www.sourcegear.com/CVS/Docs/blandy</ulink>
</para>
</listitem>
<listitem>
<para> <ulink
url="http://www.loria.fr/~molli/cvs/doc/cvs_toc.html">http://www.loria.fr/~molli/cvs/doc/cvs_toc.html</ulink></para>
</listitem>
</itemizedlist>
<section id="getaccount">
<title> Getting a CVS account </title>
<para> First you'll need to get an account at the LDP's CVS
Repository. This is pretty much the root directory that is used
by CVS, with various projects (HOWTOs, mini HOWTOs, etc.)
created as subdirectories of that. </para>
<para> You will need to create a hashed password and userid for
your account. The hashed password allows you to send an
encrypted password to the CVS group without them needing to know
your password. You can do this with the following command, from
bash (or sh): </para>
<screen format="linespecific">
<prompt>bash$</prompt> <command>echo your_password | perl -e "print crypt(&lt;&gt;,\
join '',('.', '/', 0..9, 'A'..'Z', 'a'..'z')[rand 64, rand 64]),\"\n\""</command>
</screen>
<para>Take the output of this command, and send it with your
proposed userid to
<email>pld-cvs@pld.org.pl</email>. Your unique
CVSROOT directory will be created and you'll get an e-mail with
a response. When you get your response, log into your CVSROOT
and make sure everything is set up properly: </para>
<screen format="linespecific">
<prompt>bash$</prompt> <command>export CVSROOT=:pserver:<replaceable>your_userid</replaceable>@cvs.linuxdoc.org:/cvsroot</command>
<prompt>bash$</prompt> <command>cvs -d $CVSROOT login</command>
</screen>
<para> (Replace the <replaceable>your_userid</replaceable> with what
you were sent in the response e-mail). </para>
<para> You will be asked for your password, and then given
access to the CVS Repository in read-write mode. Once you've
used <command moreinfo="none">cvs login</command> once and have
been given access to the system, your password is stored in
<filename moreinfo="none">.cvspass</filename> and you will not
have to use <command moreinfo="none">cvs login</command>
again. Just set the CVSROOT and continue on. You can get the
entire repository with this command: </para>
<screen>
<prompt>bash$</prompt> <command>cvs get LDP</command>
</screen>
<para> Or you can get the SGML source for your own document with
these commands: </para>
<screen format="linespecific">
<prompt>bash$</prompt> <command>cvs get LDP/howto/docbook/YOUR-HOWTO.sgml</command>
<prompt>bash$</prompt> <command>cvs get
guide/docbook/YOURGUIDE</command>
</screen>
</section>
<section id="othercvsnotes">
<title> Other CVS repository notes </title>
<section id="anoncvs">
<title> Anonymous CVS access </title>
<para> Anonymous CVS access is available for those who do not
require an account (such as those wishing to publish LDP
documents). This repository is read-only: </para>
<screen>
<prompt>bash$</prompt> <command>cvs -d :pserver:cvs@anoncvs.linuxdoc.org:/cvsroot login</command>
</screen>
<para> As a password, use cvs. You can then get LinuxDoc
modules as above. Note that changes to the anoncvs site may be
a half an hour behind the main site. </para>
</section>
<section id="cvsweb">
<title> CVS Files via web </title>
<para> You can access the CVS repository via the web at <ulink
url="http://cvsview.linuxdoc.org/index.cgi/?cvsroot=Linuxdoc">http://cvsview.linuxdoc.org/index.cgi/?cvsroot=Linuxdoc</ulink>.
</para>
</section>
<section id="cvsgraphics">
<title> Graphical access to CVS </title>
<para> There are graphical interfaces to CVS, and you can get
a list of them at <ulink
url="http://freshmeat.net/appindex">http://freshmeat.net/appindex</ulink>.
Search for CVS. </para>
</section>
</section>
<section id="commoncvscommands">
<title>Common CVS Commands</title>
<section id="updatingcvs">
<title>Updating files and CVS </title>
<para> CVS has a special tag, <emphasis>$Id&dollar;</emphasis>, that you
can use to automatically insert the date and version directly
into the document. After committing, CVS will turn this tag into
<emphasis>$Id$
</emphasis>. By including this tag in your document, you
can have that automatically change each time you change the
file, allowing the revision mark to increment each time. </para>
<para> When you're ready to upload changes to the CVS server,
use the command <command moreinfo="none">cvs ci -m
&quot;comment&quot; YOUR-HOWTO.sgml</command>. The -m
&quot;comment&quot; isn't necessary, but if you don't include
it, you'll be brought into the editor (usually vi, or whatever
your <envar>EDITOR</envar> environment variable is) and be given
the chance to add a comment about the changes. </para>
<para> You can follow more of the CVS discussion on the
discuss list. </para>
<para>If you are using the LDP CVS tree while developing your
document, the LDP will need to be notified when your
document is ready to be published. E-mail should be sent to
<email>submit@linuxdoc.org</email>. Indicate
the title of your document and the relative path to the
file(s) in the LDP CVS tree within your message. </para>
</section>
<section id="addnewcvs">
<title>Adding new files</title>
<para>
If your document contains graphics or multiple files, you
may come to a point where you need to add new files to
your cvs repository.
</para>
<para>
To do this, make sure that your HOWTO is in its own directory.
You may want to coordinate with the people at
<email>submit@linuxdoc.org</email> to ensure you can
add graphics or other files to your HOWTO.
</para>
<para>
Once this is set up, use <command>cvs get</command> to get
the latest copy of your HOWTO. In most cases, the command
will be similar to <command>cvs get LDP/howto/docbook/YOUR-HOWTO/</command>
assuming that your CVSROOT is set.
</para>
<para>
Copy in the files that you want to add to the repository.
The command <command>cvs add <replaceable>filename</replaceable></command>
will tell the CVS server that you want to add
<replaceable>filename</replaceable> to the repository.
You can now use <command>cvs commit</command> to commit
the changes to the CVS server. When finished, the files
are now part of the repository.
</para>
</section>
<section id="tagrelease">
<title>Creating Tag Releases</title>
<para>
Occationally, you may want to create what you call a stable
release. This is an effective way to signal to the
LDP coordinator that your document is ready for release.
This tag release specifies a specific version of your
HOWTO. This allows you to continue creating new versions
of your HOWTO without them being accidentally put
on the web site.
</para>
<para>
The downside of creating a stable (or tag) release is that
it uses the current version of the files - the last
ones submitted. Use <command>cvs commit</command> to
make sure that your files are synced up, then use
<command>cvs -q tag <replaceable>Release-x_y</replaceable></command>.
</para>
<para>
You can replace the <replaceable>Release-x_y</replaceable> with
whatever you like. However, to create a wall between CVS revisions
and tag releases, the tag release nust start with a letter
and contain letters, numbers, hyphens, or underscores.
</para>
</section>
<section id="recovery">
<title>Recovering old versions</title>
<para>
There you are, typing away, when you screw up. Real bad.
Doesn't matter what it is, but suffice to say that you've
toasted not only the version on your local drive, but
created a new version on the CVS server. What you need
to do is go back in time and resurrect and older
version of your file.
</para>
<para>
To do this, you'll need to know the version number of the
file you want to retrieve. <command>cvs diff</command>
will give a list of revisions if there are differences. You
can pick the revision number, subtract one, and that is
probably the revision you want to look at.
</para>
<para>
The command <command>cvs -Q update -p -r <replaceable>revision</replaceable></command>
<replaceable>filename</replaceable> will output to stdout
the contents of the <replaceable>revision</replaceable> version
of <replaceable>filename</replaceable>. You can pipe it to
<command>more</command> or redirect the output to a file.
Conveniently, you can redirect stdout to a file called
<replaceable>filename</replaceable>. Your local file
is now the revision you want, and <command>cvs update
</command> will update the CVS server with the new (old)
version of <replaceable>filename</replaceable>.
</para>
</section>
</section>
</section>