1
=== modified file 'bzrlib/builtins.py'
2
--- bzrlib/builtins.py	2010-08-31 08:57:28 +0000
3
+++ bzrlib/builtins.py	2010-09-13 08:23:41 +0000
4
@@ -3481,6 +3481,9 @@
5
3481
    If you set BZR_TEST_PDB=1 when running selftest, failing tests will drop
3481
    If you set BZR_TEST_PDB=1 when running selftest, failing tests will drop
6
3482
    into a pdb postmortem session.
3482
    into a pdb postmortem session.
7
3483
3483
8
3484
    The --coverage=DIRNAME global option produces a report with covered code
9
3485
    indicated.
10
3486
11
3484
    :Examples:
3487
    :Examples:
12
3485
        Run only tests relating to 'ignore'::
3488
        Run only tests relating to 'ignore'::
13
3486
3489
14
3487
3490
15
=== modified file 'doc/developers/code-style.txt'
16
--- doc/developers/code-style.txt	2010-06-02 04:39:08 +0000
17
+++ doc/developers/code-style.txt	2010-09-13 08:23:41 +0000
18
@@ -101,6 +101,38 @@
19
101
  if getattr(thing, 'name', None) is None
101
  if getattr(thing, 'name', None) is None
20
102
102
21
103
103
22
104
kwargs
23
105
======
24
106
25
107
``**kwargs`` in the prototype of a function should be used sparingly.
26
108
It can be good on higher-order functions that decorate other functions,
27
109
such as ``addCleanup`` or ``assertRaises``, or on functions that take only
28
110
(or almost only) kwargs, where any kwargs can be passed.  
29
111
30
112
Otherwise, be careful: if the parameters to a function are a bit complex
31
113
and might vary over time (e.g.  the ``commit`` API) then we prefer to pass an
32
114
object rather than a bag of positional and/or keyword args.  If you have
33
115
an arbitrary set of keys and values that are different with each use (e.g.
34
116
string interpolation inputs) then again that should not be mixed in with
35
117
the regular positional/keyword args, it seems like a different category of
36
118
thing.
37
119
38
120
39
121
Imitating standard objects
40
122
==========================
41
123
42
124
Don't provide methods that imitate built-in classes (eg ``__in__``,
43
125
``__call__``, ``__int__``, ``__getitem__``) unless the class you're
44
126
implementing really does act like the builtin class, in semantics and
45
127
performance.
46
128
47
129
For example, old code lets you say ``file_id in inv`` but we no longer
48
130
consider this good style.  Instead, say more explicitly
49
131
``inv.has_id(file_id)``.
50
132
51
133
``__repr__``, ``__cmp__``, ``__str__`` are usually fine.
52
134
53
135
54
104
Module Imports
136
Module Imports
55
105
==============
137
==============
56
106
138
57
107
139
58
=== modified file 'doc/developers/ppa.txt'
59
--- doc/developers/ppa.txt	2010-08-27 00:33:07 +0000
60
+++ doc/developers/ppa.txt	2010-09-13 08:23:41 +0000
61
@@ -15,8 +15,9 @@
62
15
15
63
16
As of June 2010, there are three PPAs:
16
As of June 2010, there are three PPAs:
64
17
17
66
18
<https://launchpad.net/~bzr/+archive>
18
<https://launchpad.net/~bzr/+archive/ppa>
67
19
    Final released versions and updates.
19
    Final released versions and updates.
68
20
    Most users who want updates to bzr should add this.
69
20
21
70
21
<https://launchpad.net/~bzr/+archive/proposed>
22
<https://launchpad.net/~bzr/+archive/proposed>
71
22
    Proposed uploads to move into ~bzr, awaiting testing.
23
    Proposed uploads to move into ~bzr, awaiting testing.
72
@@ -130,12 +131,12 @@
73
130
* Now merge across that change into each supported branch with a 
131
* Now merge across that change into each supported branch with a 
74
131
  simple ``bzr merge``.
132
  simple ``bzr merge``.
75
132
  
133
  
78
133
Locally testing builds
134
Locally testing using pbuilder
79
134
~~~~~~~~~~~~~~~~~~~~~~
135
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
80
135
136
81
136
It may be useful to locally test builds inside pbuilder.  You may want to 
137
It may be useful to locally test builds inside pbuilder.  You may want to 
82
137
use the script from <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=255165> 
138
use the script from <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=255165> 
84
138
to wrap it.
139
to wrap it, and to give it sensible defaults for your local machine.
85
139
140
86
140
Update all packages in proposed before copping the main ppa
141
Update all packages in proposed before copping the main ppa
87
141
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
142
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
88
@@ -328,7 +329,20 @@
89
328
  apt-cache madison bzr
329
  apt-cache madison bzr
90
329
  
330
  
91
330
  
331
  
92
332
Testing the contents of the PPA
93
333
-------------------------------
94
334
95
335
A somewhat crude but useful way to test the contents of the PPA is to
96
336
install the relevant packages into an schroot::
97
337
98
338
 schroot -c hardy-test -u root -- \
99
339
   apt-get install -o 'APT::Install-Suggests="true"' \
100
340
   -o 'APT::Install-Recommends="true"' \
101
341
   bzr
102
342
103
343
This should make sure everything can be installed; it won't guarantee that 
104
331
  
344
  
105
345
106
332
Packaging dependencies
346
Packaging dependencies
107
333
----------------------
347
----------------------
108
334
348
Reviewer	Review Type	Date Requested	Status
Vincent Ladeuil		2010-09-13	Needs Fixing on 2010-09-13
Review via email: mp+35243@code.launchpad.net
1	=== modified file 'bzrlib/builtins.py'
2	--- bzrlib/builtins.py 2010-08-31 08:57:28 +0000
3	+++ bzrlib/builtins.py 2010-09-13 08:23:41 +0000
4	@@ -3481,6 +3481,9 @@
5	3481	If you set BZR_TEST_PDB=1 when running selftest, failing tests will drop	3481	If you set BZR_TEST_PDB=1 when running selftest, failing tests will drop
6	3482	into a pdb postmortem session.	3482	into a pdb postmortem session.
7	3483		3483
8			3484	The --coverage=DIRNAME global option produces a report with covered code
9			3485	indicated.
10			3486
11	3484	:Examples:	3487	:Examples:
12	3485	Run only tests relating to 'ignore'::	3488	Run only tests relating to 'ignore'::
13	3486		3489
14	3487		3490
15	=== modified file 'doc/developers/code-style.txt'
16	--- doc/developers/code-style.txt 2010-06-02 04:39:08 +0000
17	+++ doc/developers/code-style.txt 2010-09-13 08:23:41 +0000
18	@@ -101,6 +101,38 @@
19	101	if getattr(thing, 'name', None) is None	101	if getattr(thing, 'name', None) is None
20	102		102
21	103		103
22			104	kwargs
23			105	======
24			106
25			107	``**kwargs`` in the prototype of a function should be used sparingly.
26			108	It can be good on higher-order functions that decorate other functions,
27			109	such as ``addCleanup`` or ``assertRaises``, or on functions that take only
28			110	(or almost only) kwargs, where any kwargs can be passed.
29			111
30			112	Otherwise, be careful: if the parameters to a function are a bit complex
31			113	and might vary over time (e.g. the ``commit`` API) then we prefer to pass an
32			114	object rather than a bag of positional and/or keyword args. If you have
33			115	an arbitrary set of keys and values that are different with each use (e.g.
34			116	string interpolation inputs) then again that should not be mixed in with
35			117	the regular positional/keyword args, it seems like a different category of
36			118	thing.
37			119
38			120
39			121	Imitating standard objects
40			122	==========================
41			123
42			124	Don't provide methods that imitate built-in classes (eg ``__in__``,
43			125	``__call__``, ``__int__``, ``__getitem__``) unless the class you're
44			126	implementing really does act like the builtin class, in semantics and
45			127	performance.
46			128
47			129	For example, old code lets you say ``file_id in inv`` but we no longer
48			130	consider this good style. Instead, say more explicitly
49			131	``inv.has_id(file_id)``.
50			132
51			133	``__repr__``, ``__cmp__``, ``__str__`` are usually fine.
52			134
53			135
54	104	Module Imports	136	Module Imports
55	105	==============	137	==============
56	106		138
57	107		139
58	=== modified file 'doc/developers/ppa.txt'
59	--- doc/developers/ppa.txt 2010-08-27 00:33:07 +0000
60	+++ doc/developers/ppa.txt 2010-09-13 08:23:41 +0000
61	@@ -15,8 +15,9 @@
62	15		15
63	16	As of June 2010, there are three PPAs:	16	As of June 2010, there are three PPAs:
64	17		17
66	18	<https://launchpad.net/~bzr/+archive>	18	<https://launchpad.net/~bzr/+archive/ppa>
67	19	Final released versions and updates.	19	Final released versions and updates.
68			20	Most users who want updates to bzr should add this.
69	20		21
70	21	<https://launchpad.net/~bzr/+archive/proposed>	22	<https://launchpad.net/~bzr/+archive/proposed>
71	22	Proposed uploads to move into ~bzr, awaiting testing.	23	Proposed uploads to move into ~bzr, awaiting testing.
72	@@ -130,12 +131,12 @@
73	130	* Now merge across that change into each supported branch with a	131	* Now merge across that change into each supported branch with a
74	131	simple ``bzr merge``.	132	simple ``bzr merge``.
75	132		133
78	133	Locally testing builds	134	Locally testing using pbuilder
79	134	~~~~~~~~~~~~~~~~~~~~~~	135	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
80	135		136
81	136	It may be useful to locally test builds inside pbuilder. You may want to	137	It may be useful to locally test builds inside pbuilder. You may want to
82	137	use the script from <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=255165>	138	use the script from <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=255165>
84	138	to wrap it.	139	to wrap it, and to give it sensible defaults for your local machine.
85	139		140
86	140	Update all packages in proposed before copping the main ppa	141	Update all packages in proposed before copping the main ppa
87	141	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~	142	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
88	@@ -328,7 +329,20 @@
89	328	apt-cache madison bzr	329	apt-cache madison bzr
90	329		330
91	330		331
92			332	Testing the contents of the PPA
93			333	-------------------------------
94			334
95			335	A somewhat crude but useful way to test the contents of the PPA is to
96			336	install the relevant packages into an schroot::
97			337
98			338	schroot -c hardy-test -u root -- \
99			339	apt-get install -o 'APT::Install-Suggests="true"' \
100			340	-o 'APT::Install-Recommends="true"' \
101			341	bzr
102			342
103			343	This should make sure everything can be installed; it won't guarantee that
104	331		344
105			345
106	332	Packaging dependencies	346	Packaging dependencies
107	333	----------------------	347	----------------------
108	334		348