/usr/share/doc/lire/dev-manual/ch17.html is in lire-devel-doc 2:2.1.1-2.1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 | <html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 17. Commit Policy</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Lire Developer's Manual"><link rel="up" href="pt04.html" title="Part IV. Lire Developers' Conventions"><link rel="prev" href="ch16s04.html" title="Some “Best Practices” on Unit Testing"><link rel="next" href="ch18.html" title="Chapter 18. Testing and debugging"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 17. Commit Policy</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch16s04.html">Prev</a> </td><th width="60%" align="center">Part IV. <span class="application">Lire</span> Developers' Conventions</th><td width="20%" align="right"> <a accesskey="n" href="ch18.html">Next</a></td></tr></table><hr></div><div class="chapter" title="Chapter 17. Commit Policy"><div class="titlepage"><div><div><h2 class="title"><a name="chap:commit-policy"></a>Chapter 17. Commit Policy</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="ch17.html#id417848">CVS Branches</a></span></dt><dd><dl><dt><span class="section"><a href="ch17.html#id417877">Hands-on example</a></span></dt><dt><span class="section"><a href="ch17.html#id417938">Naming, what it looks like</a></span></dt><dt><span class="section"><a href="ch17.html#id417989">Creating a Branch</a></span></dt><dt><span class="section"><a href="ch17.html#id418063">Accessing a Branch</a></span></dt><dt><span class="section"><a href="ch17.html#id418194">Merging Branches on the Trunk</a></span></dt></dl></dd></dl></div><p>Make sure your changes run on your own platform before
committing. Try not to break things for other platforms though.
Currently, <span class="application">Lire</span> supported platforms are GNU/Linux (<span class="productname">Debian GNU/Linux</span>™, <span class="productname">Red Hat Linux</span>™,
<span class="productname">Mandrake Linux</span>™), <span class="productname">FreeBSD</span>™, <span class="productname">OpenBSD</span>™ and <span class="productname">Solaris</span>™.
</p><p>Documentation should be updated ASAP, in case it's
obsolete or incomplete by new commits.
</p><div class="section" title="CVS Branches"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id417848"></a>CVS Branches</h2></div></div></div><p>When doing major architectural changes to <span class="application">Lire</span>,
branches in CVS are created to make it possible to
continue to fix bugs and to add small enhancements to the
stable version while development continues on the unstable
version. This applies mainly to the service repository.
The doc and package repositories generally don't need
branching.
</p><p>
BTW: A nice CVS tutorial is available in the Debian cvsbook
package.
</p><div class="section" title="Hands-on example"><div class="titlepage"><div><div><h3 class="title"><a name="id417877"></a>Hands-on example</h3></div></div></div><p>
A branching gets announced. Be sure to have all your pending
changes commited before the branching occurs. After a branch
has been made, one can do this:
</p><pre class="programlisting">
<code class="prompt">$ </code>cd ~/cvs-sourceforge/logreport
<code class="prompt">$ </code>mv service service-HEAD
<code class="prompt">$ </code>cvs co -r lire-20010924 service
<code class="prompt">$ </code>mv service service-lire-20010924
</pre><p>
or (with the same result)
</p><pre class="programlisting">
<code class="prompt">$ </code>mv service service-HEAD
<code class="prompt">$ </code>cvs co -r lire-20010924 -d service-lire-20010924 service
</pre><p>
Now, when working on stuff which should be shipped in the coming
release, one should work in service-lire-20010924. When working
on stuff which is rather fancy and experimental, and which needs
a lot of work to get stabilized, one should work in service-HEAD.
</p></div><div class="section" title="Naming, what it looks like"><div class="titlepage"><div><div><h3 class="title"><a name="id417938"></a>Naming, what it looks like</h3></div></div></div><p>Here is what branches schematically look like:
</p><pre class="programlisting">
release-20010629_1 ---> lire-unstable-20010703 ---> HEAD
\
\
lire-20010630 ---> lire-stable-20010701
</pre><p>
In this diagram a branch named
<code class="literal">lire-20010630</code> was created from the
<code class="literal">release-20010629_1</code> tag.
<code class="literal">lire-unstable-20010703</code> is another tag
on the <em class="firstterm">trunk</em> (the
<em class="firstterm">trunk</em> is the main branch).
<code class="literal">HEAD</code> isn't a real tag, it always points
to latest version on the trunk.
</p></div><div class="section" title="Creating a Branch"><div class="titlepage"><div><div><h3 class="title"><a name="id417989"></a>Creating a Branch</h3></div></div></div><p>To create a branch, one runs the command
<strong class="userinput"><code>cvs rtag -b -r
<em class="replaceable"><code>release-tag</code></em>
<em class="replaceable"><code>branch-name</code></em>
<em class="replaceable"><code>module</code></em></code></strong>. Note that
this command doesn't need a checkout version of the
repository. For example, to create the
<code class="literal">release-20010629_1-bugfixes</code> branch in the
service repository, e.g. to backport bugfixes to version
20010629_1, one would use <strong class="userinput"><code>cvs rtag -b -r
release-20010629_1 release-20010629_1-bugfixes
service</code></strong>. When ready for release, this could get
tagged as <code class="literal">release-20010629_2</code>.
</p><p>
The <em class="replaceable"><code>release-tag</code></em> should exist before
creating the branch. In case you want to branch from HEAD, use
<strong class="userinput"><code>-r HEAD</code></strong>. E.g. <strong class="userinput"><code>cvs rtag -b -r
HEAD release_1_1-branch service</code></strong>. Once Lire 1.1 gets
released, tag it as <code class="literal">release_1_1</code>.
</p></div><div class="section" title="Accessing a Branch"><div class="titlepage"><div><div><h3 class="title"><a name="id418063"></a>Accessing a Branch</h3></div></div></div><p>To start working on a particular branch, you do
<strong class="userinput"><code>cvs update -r
<em class="replaceable"><code>branch-name</code></em></code></strong>. For
example, to work on the <code class="literal">release_1_1-branch</code>
branch, you do in your checked out version,
<strong class="userinput"><code>cvs update -r release_1_1-branch</code></strong>. This
will update your copy to the version
<code class="literal">release_1_1-branch</code> and will commit all
future changes on that branch.
</p><p>Alternatively, you can also specify a branch when
checking out a module using <strong class="userinput"><code>cvs co -r
<em class="replaceable"><code>branch-name</code></em>
<em class="replaceable"><code>module</code></em></code></strong>. For
example, you could checkout the stable version of <span class="application">Lire</span>
by using <strong class="userinput"><code>cvs co -r release_1_1-branch
service</code></strong>.
</p><p>To see if you are working on a particular branch,
you can use the <strong class="userinput"><code>cvs status
<em class="replaceable"><code>file</code></em></code></strong> command. For
example, running <strong class="userinput"><code>cvs status NEWS</code></strong>
could show:
</p><pre class="screen">
===================================================================
File: NEWS Status: Up-to-date
Working revision: 1.74
Repository revision: 1.74 /cvsroot/logreport/service/NEWS,v
Sticky Tag: lire-stable
Sticky Date: (none)
Sticky Options: (none)
</pre><p>
The branch is indicated by the <code class="literal">Sticky
Tag:</code> keyword. If its value is
<code class="literal">(none)</code> you are working on the
<code class="literal">HEAD</code> branch.
</p><p>To work on the <code class="literal">HEAD</code>, you remove the
sticky tag by using the command <strong class="userinput"><code>cvs update
-A</code></strong>.
</p></div><div class="section" title="Merging Branches on the Trunk"><div class="titlepage"><div><div><h3 class="title"><a name="id418194"></a>Merging Branches on the Trunk</h3></div></div></div><p>You can bring bug fixes and small enhancements that
were made
on a branch into the unstable version on the trunk by
doing a merge. You do a merge by using the command
<strong class="userinput"><code>cvs update -j
<em class="replaceable"><code>branch-to-merge</code></em></code></strong>
in your working directory of the trunk. Conflicts are
resolved in the usual CVS way. For example, to merge the
changes of the stable branch in the development branch,
you would use <strong class="userinput"><code>cvs update -j
lire-stable</code></strong>.
</p><p>You should tag the branch after each successful
merge so that future changes can be easily merged. For
example, after merging, you do in a checked out copy of
the <code class="literal">lire-stable</code> branch:
<strong class="userinput"><code>cvs tag
lire-stable-merged-20010715</code></strong>. In this way,
one week later we can merge the week's changes of the
stable branch into the unstable branch by doing
<strong class="userinput"><code>cvs update -j lire-stable-merged-20010715 -j
lire-stable</code></strong>.
</p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch16s04.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="pt04.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch18.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Some <span class="quote">“<span class="quote">Best Practices</span>”</span> on Unit Testing </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 18. Testing and debugging</td></tr></table></div></body></html>
|