Replace old CVS references with GIT

This commit is contained in:
Matthias Bolte 2010-01-08 01:40:38 +01:00
parent edcae5a7c4
commit 728e9229b1
7 changed files with 15 additions and 15 deletions

View File

@ -15,14 +15,14 @@ should work:
or:
cvs diff -up > libvirt-myfeature.patch
git diff > libvirt-myfeature.patch
(3) Split large changes into a series of smaller patches, self-contained
if possible, with an explanation of each patch and an explanation of how
the sequence of patches fits together.
(4) Make sure your patches apply against libvirt CVS. Developers
only follow CVS and don't care much about released versions.
(4) Make sure your patches apply against libvirt GIT. Developers
only follow GIT and don't care much about released versions.
(5) Run the automated tests on your code before submitting any changes.
In particular, configure with compile warnings set to -Werror:

View File

@ -119,7 +119,7 @@
packages as well as the public headers to compile against libxenstore.</p>
</li>
<li>
<em>I use the CVS version and there is no configure script</em>
<em>I use the GIT version and there is no configure script</em>
<p>The configure script (and other Makefiles) are generated. Use the
autogen.sh script to regenerate the configure script and Makefiles,
like:</p>

View File

@ -16,7 +16,7 @@
<p>
If you are using official libvirt binaries from a Linux distribution
check below for distribution specific bug reporting policies first.
For general libvirt bug reports, from self-built releases, CVS snapshots
For general libvirt bug reports, from self-built releases, GIT snapshots
and any other non-distribution supported builds, enter tickets under
the <code>Virtualization Tools</code> product and the <code>libvirt</code>
component.
@ -64,8 +64,8 @@
</p>
<ul>
<li>The version number of the libvirt build, or date of the CVS
checkout</li>
<li>The version number of the libvirt build, or SHA1 of the GIT
commit</li>
<li>The hardware architecture being used</li>
<li>The name of the hypervisor (Xen, QEMU, KVM)</li>
<li>The XML config of the guest domain if relevant</li>

View File

@ -12,8 +12,8 @@
<a href="https://www.redhat.com/mailman/listinfo/libvir-list">associated Web</a>
page and follow the instructions. Patches with explanations and provided as
attachments are really appreciated and will be discussed on the mailing list.
If possible generate the patches by using <code>cvs diff -up</code> in a CVS
checkout.
If possible generate the patches by using <code>git diff</code> in a GIT
clone.
</p>
<h2>IRC discussion</h2>

View File

@ -25,10 +25,10 @@
# make install
</pre>
<h2>Built from CVS / GIT</h2>
<h2>Built from GIT</h2>
<p>
When building from CVS it is necessary to generate the autotools
When building from GIT it is necessary to generate the autotools
support files. This requires having <code>autoconf</code>,
<code>automake</code>, <code>libtool</code> and <code>intltool</code>
installed. The process can be automated with the <code>autogen.sh</code>

View File

@ -19,13 +19,13 @@
or:
</p>
<pre>
cvs diff -up > libvirt-myfeature.patch
git diff > libvirt-myfeature.patch
</pre></li>
<li>Split large changes into a series of smaller patches, self-contained
if possible, with an explanation of each patch and an explanation of how
the sequence of patches fits together.</li>
<li>Make sure your patches apply against libvirt CVS. Developers
only follow CVS and don't care much about released versions.</li>
<li>Make sure your patches apply against libvirt GIT. Developers
only follow GIT and don't care much about released versions.</li>
<li><p>Run the automated tests on your code before submitting any changes.
In particular, configure with compile warnings set to -Werror:</p>
<pre>

View File

@ -367,7 +367,7 @@ if HAVE_RPCGEN
# Maintainer-only target for re-generating the derived .c/.h source
# files, which are actually derived from the .x file.
#
# For committing protocol changes to CVS, the GLIBC rpcgen *must*
# For committing protocol changes to GIT, the GLIBC rpcgen *must*
# be used.
#
# Support for non-GLIB rpcgen is here as a convenience for