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
|
# -*- mode: python; coding: utf-8 -*-
# vim:smartindent cinwords=if,elif,else,for,while,try,except,finally,def,class:ts=4:sts=4:sta:et:ai:shiftwidth=4
#
# Copyright © 2004, 2005 Canonical Ltd.
# Author: Robert Collins <robertc@robertcollins.net>
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
To run this program, ensure that the pqm directory is present on your python path as
pqm
i.e. export PYTHONPATH=$(pwd), or
ln -s $(pwd)/pqm /directory-in-PYTHONPATH.
There is a ConfigManager config in the file 'pqm.config' that will pull in
dependencies from the web.
bzr support:
the bzr tree should be present as ./bzr, OR bzrlib must be accessible via
your system path.
bzr support should work with two branches directly, and bzr configured to
perform other push/publish activities. the two direct branches will be:
* The branch that the merge is being sent to (which may not be directly accessible to the submitter).
* A temporary branch that make check is run in, then bzr commit, and finally a bzr push to publish it back to the private branch.
To setup bzr support one will need to:
* Create a [URL] section for the branch. This can be a prefix
i.e. [file:///home/repos/foo/]
or an actual branch:
i.e. [file:///home/repos/foo/mainline]
* PQM then knows enough that a 'merge MYURL file:///home/repos/foo/release-1.0' command will be interpreted as:
* bzr branch file:///home/repos/foo/release-1.0
* bzr merge MYURL
* perform precommit tests
* bzr commit -m message
* bzr push file:///home/repos/foo/release-1.0
A common setup with arch is to refer to things by name. This allows for users
on local systems - say nfs - to see a copy of the branch without having any
access to the actual mainline - just like a maintainer with bzr operates.
(The local branch on the maintainers machine is their private copy, the one
they push to their website is the published copy).
To do this with pqm, setup a branch with a published_at url.
[file:///home/pqm/repos/foo/]
published_at=file:///home/repos/foo/
Here pqm will treat requests for file:///home/pqm/repos/foo/mainline and
file:///home/repos/foo/mainline identically. Additionally, it will
perform a push from the private branch to the published_at location after
every operation. It may be a good idea to give bzr direct support for this
to allow postcommit hooks to duplicate this for individual developers. One
way would be an x-push-label in the branch, so that the following does the
right thing:
'bzr branch private local'
'change a file'
'bzr commit -m message'
'bzr push' (return the change to the branch)
'bzr push public' (publish it to the world)
If your published_at location is not writable, you can overide the
'bzr push public' behaviour by setting 'publish_to' in the branch stanza.
URL overrides
-------------
Its often convenient when using 'configs' to have a local url that is faster
than the official url - for example local file system rather than sftp.
PQM supports location overrides.
if you want PQM to consider '/home/archives' to be equivalent to
'sftp://homeserver.com/home/archives', just place the following in your
pqm.conf:
[location overrides]
/home/archives=sftp://homeserver.com/home/archives
Currently this is only applied to configs, it will be extended to supplant
the similar published_at mechanism in due course. (help wanted)
TODO:
make-repo needs the api changed so that the user can say
'make a bzr repo' or
'make a XXX repo'
create-version should go - we should have vcs implementations
make versions etc as needed.
published_at must be a prefix if the url is a prefix, or not if
the url isn't one. Ditto for publish_to.
- SFTP lock failures seem to bubble up to pqm - bzr fix needed ?
- use URLMapper & location overrides for published_at.
|