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:
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>
<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.
</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>
<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>
# 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>
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>
# 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