ALT Linux Sisyphus - Пакет arch-pqm

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Introduction to the arch patch queue manager</title><meta name="generator" content="DocBook XSL Stylesheets V1.61.2"><meta name="keywords" content="arch, tla, arch-pqm, patch, changeset, archive"></head>

<body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="id2799432"></a>Introduction to the arch patch queue manager</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Colin</span> <span class="surname">Walters</span></h3></div></div><div><div class="legalnotice"><p>Copyright 2003 Colin Walters.  Permission is granted to copy,
      distribute and/or modify this document under the terms of the GPL.</p><p>Portions
Copyright (c) 2004 Robert Collins. Permission is granted to copy,
distribute and/or modify this document under the terms of the GPL.</p></div></div></div><div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><a href="#id2851143">Getting arch-pqm</a></dt><dt><a href="#id2799989">What problem does it solve?</a></dt><dt><a href="#id2801819">How it works</a></dt><dd><dl><dt><a href="#id2798688">Handling conflicts</a></dt><dt><a href="#id2798709">Running tests</a></dt><dt><a href="#id2798736">Security</a></dt></dl></dd><dt><a href="#id2798609">Setup</a></dt><dd><dl><dt><a href="#id2798617">Requirements</a></dt><dt><a href="#id2798654">Compilation and installation</a></dt></dl></dd><dt><a href="#id2799018">Using arch-pqm</a></dt><dd><dl><dt><a href="#id2799031">Defining the upstream archive</a></dt><dt><a href="#id2799056">Submitting a merge request via a shared filesystem</a></dt><dt><a href="#id2799119">Submitting a merge request via GNUPG-signed email</a></dt><dt><a href="#id2799194">Processing merge requests</a></dt></dl></dd></dl></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both;"><a id="id2851143"></a>Getting <span class="application">arch-pqm</span></h2></div></div><div></div></div><p>
      Source tarballs are available <a href="http://web.verbum.org/arch-pqm/download/" target="_top">here</a>.
    </p><p>
      <span class="application">arch-pqm</span> is also maintained in <b class="command">arch</b>.
    </p><div class="variablelist"><p class="title"><b>'official' <span class="application">arch-pqm</span> archive location</b></p><dl><dt><span class="term">Archive</span></dt><dd><p>walters@verbum.org--2003</p></dd><dt><span class="term">Location</span></dt><dd><p><a href="http://arch.verbum.org/arch" target="_top">http://arch.verbum.org/arch</a></p></dd><dt><span class="term">Revision</span></dt><dd><p>arch-pqm--main--<i class="replaceable"><tt>version</tt></i></p></dd></dl></div><div class="variablelist"><p class="title"><b>Robert Collins' <span class="application">arch-pqm</span> archive location</b></p><dl><dt><span class="term">Archive</span></dt><dd><p>rbtcollins@hotmail.com--2003</p></dd><dt><span class="term">Location</span></dt><dd><p><a href="http://people.initd.org/robertc/arch/public" target="_top">http://people.initd.org/robertc/arch/public</a></p></dd><dt><span class="term">Revision</span></dt><dd><p>arch-pqm--mainline--<i class="replaceable"><tt>version</tt></i></p></dd></dl></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both;"><a id="id2799989"></a>What problem does it solve?</h2></div></div><div></div></div><p>
      The idea is simple.  You have a project with a number of
      developers.  With a revision control system like CVS, it's
      obvious that the project code will be kept in a single
      repository, which all the developers use.  You really don't have
      much of a choice.
    </p><p>
      But arch is fully distributed.  You want to take advantage of
      those features, allowing your developers to commit while
      disconnected (say while they are travelling with a laptop),
      easily create their own temporary branches without affecting the
      main repository, and more.  To accomplish these things, each
      developer needs to have their own arch archive.
    </p><p>
      This then raises a question - where <span class="emphasis"><em>is</em></span> the
      project?  One solution is to pick a specific developer to
      perform the task of merging in the other developer's code.  That
      developer's archive becomes the canonical one for the project.
    </p><p>
      However, there is a better way.  The main idea of the <span class="application">tla</span>
      patch queue manager is to have a special archive which is
      managed entirely by the patch queue software.
    </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both;"><a id="id2801819"></a>How it works</h2></div></div><div></div></div><p>
      You create the distinguished archive to be managed by the patch
      queue manager.  Then, every developer branches off of it.  When
      a developer has reached a milestone and wants to sync up the
      main tree with their archive, they submit a merge request.
    </p><p>
      Essentially, this just leverages tla's "star-merge"
      functionality to perform the actual merge.
    </p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2798688"></a>Handling conflicts</h3></div></div><div></div></div><p>
	One question that arises at this point - what happens if
	there's a conflict?  If two people submit merge requests, the
	second could conflict with the first.  Obviously the patch
	queue manager is not an AI; it can't automatically resolve all
	conflicts.  So the simple solution is to just to inform the
	submitter of the second patch of this fact, and reject the
	merge request.  They can then sync up their tree with the main
	branch, and resubmit the merge request.
      </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2798709"></a>Running tests</h3></div></div><div></div></div><p>
	However, textual conflicts aren't the only kind of conflict;
	you could also have _semantic_ conflicts, where the patches
	don't touch the exact same portion of code, but taken together
	they break it.  One way to help solve this problem is to run a
	testsuite before every commit to the main archive.  The <span class="application">tla</span>
	patch queue manager lets you do this with a precommit hook.
	You can actually do pretty much anything you want inside this
	hook.
      </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2798736"></a>Security</h3></div></div><div></div></div><p>
	You have two choices for submitting merge requests; one option
	is to send them via email.  <span class="application">arch-pqm</span> supports GPG-signed
	messages for security.
      </p><p>
	If it can be arranged for developers to all have write access
	to the same filesystem (via NFS/SFS, over sftp, etc), then you
	can have them simply drop merge requests into a special queue
	directory.
      </p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both;"><a id="id2798609"></a>Setup</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2798617"></a>Requirements</h3></div></div><div></div></div><div class="orderedlist"><ol type="1"><li><p>Python 2.3 (or Python 2.2 and the python-logging module)</p></li><li><p>GNUPG (optional, but <span class="emphasis"><em>highly</em></span> recommended)</p></li></ol></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2798654"></a>Compilation and installation</h3></div></div><div></div></div><div class="orderedlist"><ol type="1"><li><p>
	    Use the normal <tt class="literal">configure</tt>,
	    <tt class="literal">make</tt>, <tt class="literal">make install</tt>
	    commands to install the software.
	  </p></li><li><p>
	    Next, choose a directory for <span class="application">arch-pqm</span> to use to store
	    the queued requests, as well as its log file and temporary
	    working directories.  From now on, we will assume you have
	    chosen <tt class="filename">/usr/src/arch-pqm/</tt>; adjust the path to suit yourself.
	  </p></li><li><p>
	    Set the <tt class="literal">id</tt> of the archive, using the following command:
	  </p><pre class="screen">$ HOME=<tt class="filename">/usr/src/arch-pqm/</tt> tla my-id 'Example &lt;example-dev@example.com&gt;'
	  </pre><p>
	    Note that the <tt class="literal">id</tt> you choose should not
	    be specific to one of your developers; instead choose a
	    generic name that closely corresponds to the product.  A
	    good choice would be the name of the development mailing
	    list.
	  </p></li><li><p>
	    Next, create the archive which will hold the software, and set up the
	    various categories you want:
	  </p><pre class="screen">$ HOME=<tt class="filename">/usr/src/arch-pqm/</tt> tla make-archive example-dev@example.com--2003 /usr/src/example
$ HOME=<tt class="filename">/usr/src/arch-pqm/</tt> tla my-default-archive example-dev@example.com--2003
$ HOME=<tt class="filename">/usr/src/arch-pqm/</tt> tla archive-setup hello-world--mainline--1.0
$ HOME=<tt class="filename">/usr/src/arch-pqm/</tt> tla archive-setup libhello--mainline--3.4
	  </pre></li><li><p>
	    At this point, you have two choices.  If you have an
	    existing arch repository with your code, you will likely
	    want to make the new archive have a tag from your previous
	    one, so you don't lose any history.
	  </p><pre class="screen">$ HOME=<tt class="filename">/usr/src/arch-pqm/</tt> tla tag jane@example.com--2003/hello-world--mainline--1.0 hello-world--mainline--1.0
	  </pre><p>
	    Alternatively, you could use the normal <b class="command">tla
	    import</b> command to import an existing project
	    from source.
	  </p></li><li><p>
	    Now, you need to register the other developer's archives:
	  </p><pre class="screen">$ HOME=<tt class="filename">/usr/src/arch-pqm/</tt> tla register-archive hacker1@example.com--2003 http://devserv.example.com/archives/hacker1
$ HOME=<tt class="filename">/usr/src/arch-pqm/</tt> tla register-archive james@example.com--2003 http://branch.example.co.uk/archives/james
	  </pre></li><li><p>
	    Next, you need to create a
	    <tt class="filename">~/.arch-pqm.conf</tt> configuration file.
	    This lists the location of the queue, the path to the
	    GNUPG keyring, whether or not to verify signatures, etc.
	    In addition, the <tt class="filename">arch-pqm.conf</tt> file
	    also specifies which archives are valid to merge into.  In
	    the future, it will also allow specifying a keyring
	    per-archive, and some other nice things. 
	  </p><p>
	    Please see the example file <tt class="filename">sample-arch-pqm.conf</tt> as a starting point. This documents all the options to arch-pqm.
	  </p></li><li><p>
	    Finally, have each developer register the central archive,
            and create branches from it.
	  </p></li></ol></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both;"><a id="id2799018"></a>Using <span class="application">arch-pqm</span></h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2799031"></a>Defining the upstream archive</h3></div></div><div></div></div><p>The commands in this section will be easier if we record
      in a little file which archive is the "upstream".  It is
      recommended you do something like this:
      </p><pre class="screen">$ echo 'example-dev@example.com'/$(tla parse-package-name --non-arch $(tla tree-version)) &gt; {arch}/+upstream
</pre></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2799056"></a>Submitting a merge request via a shared filesystem</h3></div></div><div></div></div><p>If you can provide all of the developers with write access
      to the same filesystem, then you can simply have them place
      merge request files in the queue directory, using a small shell
      script such as this:
    </p><pre class="programlisting">#!/bin/sh (echo "From: $(tla my-id)"; echo "Subject: $1"; echo; echo
star-merge "$(tla tree-version)" "$(cat {arch}/+upstream)") &gt;
<tt class="filename">/usr/src/arch-pqm/</tt>patch.$(date +%s)
    </pre><p>
      Save that as <tt class="filename">tla-submit-merge</tt>.  Then you
      would use this script by saying:
    </p><pre class="screen">$ tla-submit-merge 'fix lots of bugs'
</pre><p>
      In the future, we would like to have better support integrated
      in <span class="application">tla</span> for this kind of thing.
    </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2799119"></a>Submitting a merge request via GNUPG-signed email</h3></div></div><div></div></div><p>
	If your site is widely distributed, or giving shell accounts
	to all developers doesn't work well, you can also use
	GNUPG-signed email.  Here's how you could modify the script
	above:
      </p><pre class="programlisting">#!/bin/sh
echo star-merge "$(tla tree-version)" "$(cat {arch}/+upstream)" | gpg --clearsign | mail -s "$1" "$2"
</pre><p>
      You might use the above script by saying:
    </p><pre class="screen">$ tla-submit-merge 'fix bugs' pqm@example.com 	
</pre><p>
      In order to process requests sent by email, you will likely want
      to use <b class="command">procmail</b>.  If you have an account
      dedicated to processing merge requests (a good idea), you could
      use this sample <tt class="filename">.procmailrc</tt> entry:
    </p><pre class="programlisting">:0:
| arch-pqm --read
    </pre><p>
      If you don't have a dedicated account, you will have to pick a
      specific Subject: or other header to use to differentiate merge
      requests from your regular email.
    </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2799194"></a>Processing merge requests</h3></div></div><div></div></div><p>
	The key command is:
      </p><pre class="screen">$ arch-pqm --run
      </pre><p>
	That simply iterates through the pending merge requests in
	order (by <tt class="literal">mtime</tt>), and processes them.  A
	good way to use this would be to run it via a
	<b class="command">cron</b> job.
      </p></div></div></div></body></html>

5.1:	0.5-alt1.1
4.1:	0.5-alt1.1
4.0:	0.5-alt1
3.0:	0.5-alt1