Rev 5458: Merge doc-new-config into next in file:///home/vila/src/bzr/experimental/config/
Vincent Ladeuil
v.ladeuil+lp at free.fr
Fri Nov 19 07:31:35 GMT 2010
At file:///home/vila/src/bzr/experimental/config/
------------------------------------------------------------
revno: 5458 [merge]
revision-id: v.ladeuil+lp at free.fr-20101119073135-mker1kf161hq2ldx
parent: v.ladeuil+lp at free.fr-20101112110651-f0ytplf5uk652hly
parent: v.ladeuil+lp at free.fr-20101119073133-km72tlto9ikcw2l0
committer: Vincent Ladeuil <v.ladeuil+lp at free.fr>
branch nick: next
timestamp: Fri 2010-11-19 08:31:35 +0100
message:
Merge doc-new-config into next
modified:
bzrlib/branchbuilder.py branchbuilder.py-20070427022007-zlxpqz2lannhk6y8-1
bzrlib/config.py config.py-20051011043216-070c74f4e9e338e8
bzrlib/merge.py merge.py-20050513021216-953b65a438527106
bzrlib/msgeditor.py msgeditor.py-20050901111708-ef6d8de98f5d8f2f
bzrlib/smart/repository.py repository.py-20061128022038-vr5wy5bubyb8xttk-1
bzrlib/tests/test_branchbuilder.py test_branchbuilder.p-20070427022007-zlxpqz2lannhk6y8-2
bzrlib/tests/test_config.py testconfig.py-20051011041908-742d0c15d8d8c8eb
bzrlib/tests/test_merge.py testmerge.py-20050905070950-c1b5aa49ff911024
bzrlib/tests/test_msgeditor.py test_msgeditor.py-20051202041359-920315ec6011ee51
doc/developers/configuration.txt configuration.txt-20101028230246-6o422fzpie7gczx9-1
doc/developers/groupcompress-design.txt design-20080705181503-ccbxd6xuy1bdnrpu-2
doc/developers/incremental-push-pull.txt incrementalpushpull.-20070508045640-zneiu1yzbci574c6-1
doc/developers/integration.txt integration.txt-20080404022341-2lorxocp1in07zij-1
doc/developers/performance-roadmap-rationale.txt performanceroadmapra-20070507174912-mwv3xv517cs4sisd-1
doc/developers/performance-use-case-analysis.txt performanceusecasean-20070508045640-zneiu1yzbci574c6-2
doc/developers/planned-change-integration.txt plannedchangeintegra-20070619004702-i1b3ccamjtfaoq6w-1
doc/developers/planned-performance-changes.txt plannedperformancech-20070604053752-bnjdhako613xfufb-1
doc/developers/repository.txt repository.txt-20070709152006-xkhlek456eclha4u-1
doc/developers/revert.txt revert.txt-20070515111013-grc9hgp21zxqbwbl-1
doc/developers/tortoise-strategy.txt tortoisestrategy.txt-20080403024510-2ahdqrvnwqrb5p5t-1
doc/en/release-notes/bzr-2.3.txt NEWS-20050323055033-4e00b5db738777ff
-------------- next part --------------
=== modified file 'bzrlib/branchbuilder.py'
--- a/bzrlib/branchbuilder.py 2010-02-27 12:27:33 +0000
+++ b/bzrlib/branchbuilder.py 2010-11-18 08:13:01 +0000
@@ -21,6 +21,7 @@
commit,
errors,
memorytree,
+ revision,
)
@@ -186,7 +187,10 @@
:return: The revision_id of the new commit
"""
if parent_ids is not None:
- base_id = parent_ids[0]
+ if len(parent_ids) == 0:
+ base_id = revision.NULL_REVISION
+ else:
+ base_id = parent_ids[0]
if base_id != self._branch.last_revision():
self._move_branch_pointer(base_id,
allow_leftmost_as_ghost=allow_leftmost_as_ghost)
=== modified file 'bzrlib/config.py'
--- a/bzrlib/config.py 2010-11-09 16:26:07 +0000
+++ b/bzrlib/config.py 2010-11-17 15:51:10 +0000
@@ -1866,9 +1866,12 @@
break
for (oname, value, section, conf_id, parser) in c._get_options():
if name == oname:
- # Display only the first value and exit (We need to use
- # get_user_option to take policies into account and we need
- # to make sure the option exists too :-/)
+ # Display only the first value and exit
+
+ # FIXME: We need to use get_user_option to take policies
+ # into account and we need to make sure the option exists
+ # too (hence the two for loops), this needs a better API
+ # -- vila 20101117
value = c.get_user_option(name)
# Quote the value appropriately
value = parser._quote(value)
=== modified file 'bzrlib/merge.py'
--- a/bzrlib/merge.py 2010-08-25 13:02:32 +0000
+++ b/bzrlib/merge.py 2010-11-18 08:22:54 +0000
@@ -582,6 +582,7 @@
elif len(lcas) == 1:
self.base_rev_id = list(lcas)[0]
else: # len(lcas) > 1
+ self._is_criss_cross = True
if len(lcas) > 2:
# find_unique_lca can only handle 2 nodes, so we have to
# start back at the beginning. It is a shame to traverse
@@ -592,22 +593,30 @@
else:
self.base_rev_id = self.revision_graph.find_unique_lca(
*lcas)
- self._is_criss_cross = True
+ sorted_lca_keys = self.revision_graph.find_merge_order(
+ revisions[0], lcas)
+ if self.base_rev_id == _mod_revision.NULL_REVISION:
+ self.base_rev_id = sorted_lca_keys[0]
+
if self.base_rev_id == _mod_revision.NULL_REVISION:
raise errors.UnrelatedBranches()
if self._is_criss_cross:
trace.warning('Warning: criss-cross merge encountered. See bzr'
' help criss-cross.')
trace.mutter('Criss-cross lcas: %r' % lcas)
- interesting_revision_ids = [self.base_rev_id]
- interesting_revision_ids.extend(lcas)
+ if self.base_rev_id in lcas:
+ trace.mutter('Unable to find unique lca. '
+ 'Fallback %r as best option.' % self.base_rev_id)
+ interesting_revision_ids = set(lcas)
+ interesting_revision_ids.add(self.base_rev_id)
interesting_trees = dict((t.get_revision_id(), t)
for t in self.this_branch.repository.revision_trees(
interesting_revision_ids))
self._cached_trees.update(interesting_trees)
- self.base_tree = interesting_trees.pop(self.base_rev_id)
- sorted_lca_keys = self.revision_graph.find_merge_order(
- revisions[0], lcas)
+ if self.base_rev_id in lcas:
+ self.base_tree = interesting_trees[self.base_rev_id]
+ else:
+ self.base_tree = interesting_trees.pop(self.base_rev_id)
self._lca_trees = [interesting_trees[key]
for key in sorted_lca_keys]
else:
=== modified file 'bzrlib/msgeditor.py'
--- a/bzrlib/msgeditor.py 2010-09-13 10:04:19 +0000
+++ b/bzrlib/msgeditor.py 2010-11-11 13:45:02 +0000
@@ -208,28 +208,25 @@
def _create_temp_file_with_commit_template(infotext,
ignoreline=DEFAULT_IGNORE_LINE,
- start_message=None):
+ start_message=None,
+ tmpdir=None):
"""Create temp file and write commit template in it.
- :param infotext: Text to be displayed at bottom of message
- for the user's reference;
- currently similar to 'bzr status'.
- The text is already encoded.
+ :param infotext: Text to be displayed at bottom of message for the
+ user's reference; currently similar to 'bzr status'. The text is
+ already encoded.
:param ignoreline: The separator to use above the infotext.
- :param start_message: The text to place above the separator, if any.
- This will not be removed from the message
- after the user has edited it.
- The string is already encoded
+ :param start_message: The text to place above the separator, if any.
+ This will not be removed from the message after the user has edited
+ it. The string is already encoded
:return: 2-tuple (temp file name, hasinfo)
"""
import tempfile
tmp_fileno, msgfilename = tempfile.mkstemp(prefix='bzr_log.',
- dir='.',
- text=True)
- msgfilename = osutils.basename(msgfilename)
+ dir=tmpdir, text=True)
msgfile = os.fdopen(tmp_fileno, 'w')
try:
if start_message is not None:
=== modified file 'bzrlib/smart/repository.py'
--- a/bzrlib/smart/repository.py 2010-05-14 13:36:34 +0000
+++ b/bzrlib/smart/repository.py 2010-11-16 06:06:11 +0000
@@ -30,7 +30,6 @@
osutils,
pack,
ui,
- versionedfile,
)
from bzrlib.bzrdir import BzrDir
from bzrlib.smart.request import (
@@ -39,7 +38,6 @@
SuccessfulSmartServerResponse,
)
from bzrlib.repository import _strip_NULL_ghosts, network_format_registry
-from bzrlib.recordcounter import RecordCounter
from bzrlib import revision as _mod_revision
from bzrlib.versionedfile import (
NetworkRecordStream,
@@ -506,8 +504,6 @@
for record in substream:
if record.storage_kind in ('chunked', 'fulltext'):
serialised = record_to_fulltext_bytes(record)
- elif record.storage_kind == 'inventory-delta':
- serialised = record_to_inventory_delta_bytes(record)
elif record.storage_kind == 'absent':
raise ValueError("Absent factory for %s" % (record.key,))
else:
=== modified file 'bzrlib/tests/test_branchbuilder.py'
--- a/bzrlib/tests/test_branchbuilder.py 2010-02-27 12:27:33 +0000
+++ b/bzrlib/tests/test_branchbuilder.py 2010-11-18 08:13:01 +0000
@@ -324,6 +324,21 @@
# should look like it was not modified in the merge
self.assertEqual('C-id', d_tree.inventory['c-id'].revision)
+ def test_set_parent_to_null(self):
+ builder = self.build_a_rev()
+ builder.start_series()
+ self.addCleanup(builder.finish_series)
+ builder.build_snapshot('B-id', [],
+ [('add', ('', None, 'directory', None))])
+ # We should now have a graph:
+ # A B
+ # And not A => B
+ repo = builder.get_branch().repository
+ self.assertEqual({'A-id': (_mod_revision.NULL_REVISION,),
+ 'B-id': (_mod_revision.NULL_REVISION,),},
+ repo.get_parent_map(['A-id', 'B-id']))
+
+
def test_start_finish_series(self):
builder = BranchBuilder(self.get_transport().clone('foo'))
builder.start_series()
=== modified file 'bzrlib/tests/test_config.py'
--- a/bzrlib/tests/test_config.py 2010-11-12 11:06:51 +0000
+++ b/bzrlib/tests/test_config.py 2010-11-19 07:31:35 +0000
@@ -163,6 +163,7 @@
test.locations_config = config.LocationConfig(tree.basedir)
test.bazaar_config = config.GlobalConfig()
+
def create_configs_with_file_option(test):
"""Create configuration files with a ``file`` option set in each.
=== modified file 'bzrlib/tests/test_merge.py'
--- a/bzrlib/tests/test_merge.py 2010-07-29 04:07:27 +0000
+++ b/bzrlib/tests/test_merge.py 2010-11-18 08:18:19 +0000
@@ -1270,6 +1270,26 @@
self.assertEqual(['B-id', 'C-id', 'F-id'],
[t.get_revision_id() for t in merger._lca_trees])
+ def test_find_base_new_root_criss_cross(self):
+ # A B
+ # |\ /|
+ # | X |
+ # |/ \|
+ # C D
+
+ builder = self.get_builder()
+ builder.build_snapshot('A-id', None,
+ [('add', ('', None, 'directory', None))])
+ builder.build_snapshot('B-id', [],
+ [('add', ('', None, 'directory', None))])
+ builder.build_snapshot('D-id', ['A-id', 'B-id'], [])
+ builder.build_snapshot('C-id', ['A-id', 'B-id'], [])
+ merger = self.make_Merger(builder, 'D-id')
+ self.assertEqual('A-id', merger.base_rev_id)
+ self.assertTrue(merger._is_criss_cross)
+ self.assertEqual(['A-id', 'B-id'], [t.get_revision_id()
+ for t in merger._lca_trees])
+
def test_no_criss_cross_passed_to_merge_type(self):
class LCATreesMerger(LoggingMerger):
supports_lca_trees = True
=== modified file 'bzrlib/tests/test_msgeditor.py'
--- a/bzrlib/tests/test_msgeditor.py 2010-08-29 14:32:45 +0000
+++ b/bzrlib/tests/test_msgeditor.py 2010-11-11 13:45:02 +0000
@@ -301,9 +301,12 @@
def test__create_temp_file_with_commit_template_in_unicode_dir(self):
self.requireFeature(tests.UnicodeFilenameFeature)
if hasattr(self, 'info'):
- os.mkdir(self.info['directory'])
- os.chdir(self.info['directory'])
- msgeditor._create_temp_file_with_commit_template('infotext')
+ tmpdir = self.info['directory']
+ os.mkdir(tmpdir)
+ # Force the creation of temp file in a directory whose name
+ # requires some encoding support
+ msgeditor._create_temp_file_with_commit_template('infotext',
+ tmpdir=tmpdir)
else:
raise TestNotApplicable('Test run elsewhere with non-ascii data.')
=== modified file 'doc/developers/configuration.txt'
--- a/doc/developers/configuration.txt 2010-11-01 13:20:01 +0000
+++ b/doc/developers/configuration.txt 2010-11-12 15:12:58 +0000
@@ -5,11 +5,12 @@
Goal
====
-Not all needs can be addressed by the default values, no matter how well
-they are chosen.
+Not all needs can be addressed by the default values used inside bzr and
+bzrlib, no matter how well they are chosen (and they are ;).
-Many parts of ``bzrlib`` depends on options though and the user should be
-able to customize the behavior to suit his needs.
+Many parts of ``bzrlib`` depends on some constants though and the user
+should be able to customize the behavior to suit his needs so these
+constants need to become configuration options.
These options can be set from the command-line, in an environment variable
or recorded in a configuration file.
@@ -21,10 +22,11 @@
user to look at or modify them.
* The current API requires a configuration object to create, modify or
- delete a configuration option in a given configuration file. While this
- matches the user expectations developers would be better served by
- manipulating configuration option objects directly, providing a branch,
- working tree or repository to define the context for this option.
+ delete a configuration option in a given configuration file. ``bzr
+ config`` makes it almost transparent for the user. Internally though, not
+ all cases are handled: only BranchConfig implements chained configs,
+ nothing is provided at the repository level and too many plugins define
+ their own section or even their own config file.
* ``locations.conf`` defines the options that needs to override any setting
in ``branch.conf`` for both local and remotes branches. Many users want a
@@ -42,23 +44,16 @@
* should the inherited value append the relative path between the
section one and the location it applies to.
- * the default value (including calling any python code that may is
+ * the default value (including calling any python code that may be
required to calculate this value),
- * are the rules above different for various config files
-
-* There is no way to get access to the configuration option active value
- from the command line. The "active" value is the one that ``bzr`` will
- take into account when excuting a command. Access to this value should
- be possible for all contexts:
-
- * for a given local or remote branch,
-
- * for a given section in a given configuration file.
-
-* There is no way to modify or delete a configuration option. Again, it
- should be possible to do so for any local or remote branch and any
- section of any configuration file.
+ * priority between sections and various config files
+
+* Access to the 'active' configuration option value from the command line
+ doesn't give access to specific section.
+
+* Rules for configuration options are not clearly defined for remote
+ branches (they may differ between dumb and smart servers).
* The features offered by the Bazaar configuration files should be easily
accessible to plugin authors either by supporting plugin configuration
@@ -66,7 +61,7 @@
own configuration files.
* While the actual configuration files support sections, they are used in
- mutually exclusive ways to make it impossible to offer the same set of
+ mutually exclusive ways that make it impossible to offer the same set of
features to all configuration files:
* ``bazaar.conf`` use arbitrary names for sections. ``DEFAULT`` is used
@@ -83,28 +78,32 @@
* There is no easy way to get configuration options for a given repository
or an arbitrary path. Working trees and branches are generally organized
- in hierarchies and being able to share the option definitions is a often
+ in hierarchies and being able to share the option definitions is an often
required feature. This can also address some needs exhibited by various
branch schemes like looms, pipeline, colocated branches and nested
- trees. Being able to specify options*in* a working tree could also help
+ trees. Being able to specify options *in* a working tree could also help
support conflict resolution options for a given file, directory or
subtree.
* Since sections allow different definitions for the same option, a total
order should be defined between sections to select the right definition
for a given path. Allowing globs for section names is harmful in this
- respect since the order is currently defined as being the
- lexicographical one. The caveat here is that if the order is always
- defined for a given set of sections it can change when one or several
- globs are modified and the user may get surprising and unwanted results
- in these cases. The lexicographical order is otherwise fine to define
- what section is more specific than another.
+ respect since the order is currently defined as being the lexicographical
+ one. The caveat here is that if the order is always defined for a given
+ set of sections it can change when one or several globs are modified and
+ the user may get surprising and unwanted results in these cases. The
+ lexicographical order is otherwise fine to define what section is more
+ specific than another. (This may not be a problem in real life since
+ longer globs are generally more specific than shorter ones and explicit
+ paths should also be longer than matching globs. That may leave a glob and
+ a path of equal lenght in a grey area but in practive using ``bzr config``
+ should give enough feedback to address them).
-* Internally, configuration files (and their fallbacks, ``bazaar.conf``
- and ``locatons.conf`` for ``branch.conf``) are read each time *one*
- option is queried. Likewise, setting or deleting a configuration option
- implies writing the configuration file *immediately* after re-reading
- the file to avoid racing updates.
+* Internally, configuration files (and their fallbacks, ``bazaar.conf`` and
+ ``locatons.conf`` for ``branch.conf``) are read every time *one* option is
+ queried. Likewise, setting or deleting a configuration option implies
+ writing the configuration file *immediately* after re-reading the file to
+ avoid racing updates.
* The current implementation use a mix of transport-based and direct file
systems operations.
@@ -118,8 +117,32 @@
* Inherited list values can't be modified, a more specific configuration can
only redefine the whole list.
+* There is no easy way to define dicts (the most obvious one being to use a
+ dedicated section which is already overloaded). Using embedded sections
+ for this would not be practivcal either if we keep using a no-name section
+ for default values. As a last resort, the value of such a configuration
+ option can be bencoded but that won't be user-friendly. This is not a big
+ concern so far as very few needs required dicts as option values.
+
+Proposed implementation
+=======================
+
+
+Configuration files definition
+------------------------------
+
+While of course configurations files can be versioned they are not intended
+to be accessed in sync with the files they refer too (one can imagine
+handling versioned properties this way but this is *not* what the bazaar
+configuration files are targeted at). ``bzr`` will always refer to
+configuration files as they exist on disk when an option is queried or set.
+
+The configuration files are generally local to the file system but some of
+them can be accessed remotely (branch.conf, repo.conf).
+
+
Naming
-======
+------
The option name space is organized as follow:
@@ -132,7 +155,7 @@
do so in the future).
Value
-=====
+-----
All option values are text. They are provided as Unicode strings to API
users with some refinements:
@@ -163,27 +186,31 @@
Since options values are text-only, and to avoid clashing with other
interpolation syntaxes, references are enclosed with curly brackets::
- push_location=lp:~{launchpad_username}/bzr/{nick}
+ push_location = lp:~{launchpad_username}/bzr/{nick}
In the example above, ``launchpad_username`` is an already defined
configuration option while ``nick`` is the branch nickname and is set when a
configuration applies to a given branch.
-The interpolation implementation accept an additional dict so that
+The interpolation implementation should accept an additional dict so that
``bzrlib`` or plugins can define references that can be interpolated without
being existing configuration options::
diff_command={cmd} {cmd_opts} {file_a} {file_b}
-There are two common errors that should handled when handling interpolation:
+There are two common errors that should be handled when handling interpolation:
* loops: when a configuration value refers to itself, directly or indirectly,
* undefined references: when a configuration value refers to an unknown option.
-The former can be addressed by falling back to the less specific
-configurations when a value is searched for. This allows list values to
-refer to the definition in the less specific configurations allowing::
+One possible implementation is to report errors when such references are
+encountered.
+
+Another implementation could be envisioned though: when a loop is
+encountered, we can fall back to the less specific configurations. This
+allows list values to refer to the definition in the less specific
+configurations allowing::
bazaar.conf:
debug_flags = hpss
@@ -191,26 +218,15 @@
branch.conf for mybranch:
debug_flags = {debug_flags}, hpssdetail
- $ bzr -d mybranch config -1 debug_flags
+ $ bzr -d mybranch config debug_flags
hpss, hpssdetail
Undefined references would still be detected if they are not defined in any
-configuration.
-
-Configuration files
-===================
-
-While of course configurations files can be versioned they are not intended
-to be accessed in sync with the files they refer too (one can imagine
-handling versioned properties this way but this is *not* what the bazaar
-configuration files are targeted at. ``bzr`` will always refer to
-configuration files as they exist on disk when an option is queried or set.
-
-The configuration files are generally local to the file system but some of
-them can be accessed remotely (branch.conf, repo.conf).
+configuration or just stay unresolved which should be enough to trigger
+errors displaying the value. Diagnosing typos should be doable in this case.
Configuration file syntax
-=========================
+-------------------------
The configuration file is mostly an ``ini-file``. It contains ``name =
value`` lines grouped in sections. Comments are allowed by prefixing them
@@ -219,14 +235,14 @@
A section is named by the path it should apply to (more examples below).
Options defined outside of any section act as defaults when no section
-apply. This means that in the most common cases, the user doesn't need to
+applies. This means that in the most common cases, the user doesn't need to
define any section.
When sections are used, they provide a finer grain of configuration by
-defining set of options that apply to some working trees, branches,
+defining option sets that apply to some working trees, branches,
repositories or part of them.
-The subset is defined by the common leading path.
+The subset is defined by the common leading path or a glob.
* a full url: used to described options for remote branches and
repositories.
@@ -234,17 +250,27 @@
* local absolute path: used for working trees, branches or repositories
on the local disks.
-* relative path: the path is relative to the configuration file and can
- be used for colocated branches or threads in a loom, i.e any working
- tree, branch or repository that is located in a place related to the
- configuration file path. Some configuration files may define this
- path relationship in specific ways to make them easier to use.
+* relative path: the path is relative to the configuration file and can be
+ used for colocated branches or threads in a loom, i.e any working tree,
+ branch or repository that is located in a place related to the
+ configuration file path. Some configuration files may define this path
+ relationship in specific ways to make them easier to use (i.e. if a config
+ file is somewhere below ``.bzr`` and refers to threads in a loom for
+ example, the relative path would be the thread name, it doesn't have to be
+ an *exact* relative path, as long as its interpretation is unambiguous and
+ clear for the user).
Whatever path is used, the options apply if the branch path starts with
-the path defining the section.
+the path defining the section (or if the glob matches).
The ConfigOption object
-=======================
+-----------------------
+
+In addition to the configuration files, one internal configuration dict can
+contain definitions for some configuration options. This will allow a finer
+grained definition of the default values and the online help.
+
+The ConfigOption object will define:
* name
@@ -252,18 +278,14 @@
* docstring used for the help
-* a list of config files where the option can be defined. Depending on the
- files involved, a working tree, branch or repository object should be
- provided to the API to access the corresponding configuration file. Note
- that providing a working tree object also implicitely provides the
- associated branch and repository object so only one of them is required
- (or none for configuration files specific to the user like bazaar.conf and
- locations.conf).
+* a list of config files where the option can be defined.
The ConfigFile object
-=====================
-
-* local or remote
+---------------------
+
+This is an implementation-level object that should rarely be used directly.
+
+* it can be local or remote
* locking
@@ -273,19 +295,39 @@
Working trees, branches and repositories should define a config attribute
following the same life cycle as their lock: the associated config file is
- read one and written once if needed. This should minimize the file system
+ read once and written once if needed. This should minimize the file system
accesses or the network requests. There is no known racing scenarios for
configuration options, changing the existing implementation to this less
- constraint one shouldn't introduce any. Yet, in order to detect such
+ constrained one shouldn't introduce any. Yet, in order to detect such
racing scenarios, we can check that the current content of the
configuration file is the expected one before writing the new content and
emit warnings if differences occurred. The checks should be performed for
- the modified values only.
-
-* fallback ConfigFile
+ the modified values only. As of today, the size of the configuration files
+ are small enough to be kept in memory.
+
+The Config object
+-----------------
+
+This the object that provides access to the needed features:
+
+* getting an option value,
+
+* setting an option value,
+
+* deleting an option value,
+
+* handling a list of configuration files that should be tried in the given
+ order to find an option.
+
+Depending on the files involved, a working tree, branch or repository object
+should be provided to access the corresponding configuration files. Note
+that providing a working tree object also implicitely provides the
+associated branch and repository object so only one of them is required (or
+none for configuration files specific to the user like bazaar.conf and
+locations.conf).
Getting an option value
-=======================
+~~~~~~~~~~~~~~~~~~~~~~~
Depending on the option, there are various places where it can be defined
and several ways to override these settings when needed.
@@ -296,7 +338,7 @@
express that an option is not set).
* command-line (Not Implemented Yet)
- ``-Ooption=value``
+ ``-Ooption=value`` see bug #491196.
* environment variable
@@ -322,15 +364,20 @@
Note that the sections defined there can use relative paths if some
options should apply to a subtree or some specific files only.
+ See bug #430538 and bug #654998.
+
* branch.conf
The options related to the branch.
- Sections can
+ Sections can be defined for co-located branches or loom threads.
* repo.conf (Not Implemented Yet)
- The options related to the repository
+ The options related to the repository.
+
+ Using an option to describe whether or not a repository is shared could
+ help address bug #342119 but this will probably requires a format bump).
* project.conf (Not Implemented Yet)
@@ -340,14 +387,21 @@
The options common to all branches and working trees for an organization.
+ See bug #419854.
+
* bazaar.conf
The options the user has selected for the host he is using.
+ Sections can be defined for both remote and local branches to define
+ default values (i.e. the most common use of ``locations.conf`` today).
+
* default (Not Implemented Yet)
The options defined in the ``bzr`` source code.
+ This will be implemented via the ConfigOption objects.
+
Plugins can define additional configuration files as they see fit and
insert them in this list, see their documentation for details.
@@ -362,8 +416,6 @@
future. Plugin authors are encouraged to migrate to the new name space
scheme by prefixing their options with their plugin name.
-* Globs in section names are discouraged and should be deprecated.
-
* Option policies should be deprecated:
* The ``norecurse`` policy is useless, all options are recursive by
=== modified file 'doc/developers/groupcompress-design.txt'
--- a/doc/developers/groupcompress-design.txt 2009-04-08 16:33:19 +0000
+++ b/doc/developers/groupcompress-design.txt 2010-11-12 14:28:36 +0000
@@ -29,7 +29,7 @@
Reasonable sizes 'amount read' from remote machines to reconstruct an arbitrary
text: Reading 5MB for a 100K plain text is not a good trade off. Reading (say)
-500K is probably acceptable. Reading ~100K is ideal. However, its likely that
+500K is probably acceptable. Reading ~100K is ideal. However, it's likely that
some texts (e.g NEWS versions) can be stored for nearly-no space at all if we
are willing to have unbounded IO. Profiling to set a good heuristic will be
important. Also allowing users to choose to optimise for a server environment
=== modified file 'doc/developers/incremental-push-pull.txt'
--- a/doc/developers/incremental-push-pull.txt 2009-12-02 20:34:07 +0000
+++ b/doc/developers/incremental-push-pull.txt 2010-11-12 14:28:36 +0000
@@ -32,7 +32,7 @@
1. New data is identified in the source repository.
2. That data is read from the source repository.
3. The same data is verified and written to the target repository in such a
- manner that its not visible to readers until its ready for use.
+ manner that it's not visible to readers until it's ready for use.
New data identification
~~~~~~~~~~~~~~~~~~~~~~~
@@ -119,7 +119,7 @@
ghost points from the target; plus a set difference search is needed on
signatures.
- * Semantic level can probably be tuned, but as its also complex I suggest
+ * Semantic level can probably be tuned, but as it's also complex I suggest
deferring analysis for optimal behaviour of this use case.
@@ -180,7 +180,7 @@
validate the contents of a revision we need the new texts in the inventory for
the revision - to check a fileid:revisionid we need to know the expected sha1
of the full text and thus also need to read the delta chain to construct the
-text as we accept it to determine if its valid. Providing separate validators
+text as we accept it to determine if it's valid. Providing separate validators
for the chosen representation would address this.
e.g: For an inventory entry FILEID:REVISIONID we store the validator of the
full text :SHA1:. If we also stored the validator of the chosen disk
=== modified file 'doc/developers/integration.txt'
--- a/doc/developers/integration.txt 2010-05-16 09:29:44 +0000
+++ b/doc/developers/integration.txt 2010-11-12 14:28:36 +0000
@@ -43,7 +43,7 @@
This gives us a WorkingTree object, which has various methods spread over
-itself, and its parent classes MutableTree and Tree - its worth having a
+itself, and its parent classes MutableTree and Tree - it's worth having a
look through these three files (workingtree.py, mutabletree.py and tree.py)
to see which methods are available.
=== modified file 'doc/developers/performance-roadmap-rationale.txt'
--- a/doc/developers/performance-roadmap-rationale.txt 2007-06-05 08:02:04 +0000
+++ b/doc/developers/performance-roadmap-rationale.txt 2010-11-12 14:28:36 +0000
@@ -109,7 +109,7 @@
of great assistance I think. We want to help everyone that wishes to
contribute to performance to do so effectively.
-Finally, its important to note that coding is not the only contribution
+Finally, it's important to note that coding is not the only contribution
- testing, giving feedback on current performance, helping with the
analysis are all extremely important tasks too and we probably want to
have clear markers of where that should be done to encourage such
=== modified file 'doc/developers/performance-use-case-analysis.txt'
--- a/doc/developers/performance-use-case-analysis.txt 2009-12-02 20:34:07 +0000
+++ b/doc/developers/performance-use-case-analysis.txt 2010-11-12 14:28:36 +0000
@@ -38,7 +38,7 @@
be constant time. Retrieval of the annotated text should be roughly
constant for any text of the same size regardless of the number of
revisions contributing to its content. Mapping of the revision ids to
-dotted revnos could be done as the text is retrieved, but its completely
+dotted revnos could be done as the text is retrieved, but it's completely
fine to post-process the annotated text to obtain dotted-revnos.'
What factors should be considered?
@@ -79,7 +79,7 @@
- locality of reference: If an operation requires data that is located
within a small region at any point, we often get better performance
than with an implementation of the same operation that requires the
- same amount of data but with a lower locality of reference. Its
+ same amount of data but with a lower locality of reference. It's
fairly tricky to add locality of reference after the fact, so I think
its worth considering up front.
@@ -102,8 +102,8 @@
file-level operation latency considerations.
Many performance problems only become visible when changing the scaling knobs
-upwards to large trees. On small trees its our baseline performance that drives
-incremental improvements; on large trees its the amount of processing per item
+upwards to large trees. On small trees it's our baseline performance that drives
+incremental improvements; on large trees it's the amount of processing per item
that drives performance. A significant goal therefore is to keep the amount of
data to be processed under control. Ideally we can scale in a sublinear fashion
for all operations, but we MUST NOT scale even linearly for operations that
=== modified file 'doc/developers/planned-change-integration.txt'
--- a/doc/developers/planned-change-integration.txt 2010-06-02 05:03:31 +0000
+++ b/doc/developers/planned-change-integration.txt 2010-11-12 14:28:36 +0000
@@ -66,7 +66,7 @@
* Network-efficient revision graph API: This influences what questions we will
want to ask a local repository very quickly; as such it's a driver for the
- new repository format and should be in place first if possible. Its probably
+ new repository format and should be in place first if possible. It's probably
not sufficiently different to local operations to make this a hard ordering
though.
@@ -91,14 +91,14 @@
* Repository stacking API: The key dependency/change required for this is that
repositories must individually be happy with having partial data - e.g. many
ghosts. However the way the API needs to be used should be driven from the
- command layer in, because its unclear at the moment what will work best.
+ command layer in, because it's unclear at the moment what will work best.
* Revision stream API: This API will become clear as we streamline commands.
On the data insertion side commit will want to generate new data. The
commands pull, bundle, merge, push, possibly uncommit will want to copy
existing data in a streaming fashion.
- * New container format: Its hard to tell what the right way to structure the
+ * New container format: It's hard to tell what the right way to structure the
layering is. Probably having smooth layering down to the point that code
wants to operate on the containers directly will make this more clear. As
bundles will become a read-only branch & repository, the smart server wants
@@ -135,7 +135,7 @@
today, it is likely able to be implemented immediately, but we are not sure
that its needed anymore, so it is being shelved.
- * Removing derivable data: Its very hard to do this while the derived data is
+ * Removing derivable data: It's very hard to do this while the derived data is
exposed in API's but not used by commands. Implemented the targeted API's
for our core use cases should allow use to remove accidental use of derived
data, making only explicit uses of it visible, and isolating the impact of
=== modified file 'doc/developers/planned-performance-changes.txt'
--- a/doc/developers/planned-performance-changes.txt 2010-08-13 19:08:57 +0000
+++ b/doc/developers/planned-performance-changes.txt 2010-11-12 14:28:36 +0000
@@ -43,7 +43,7 @@
without changing disk, possibly with a performance hit until the disk
formats match the validatory logic. It will be hard to tell if we have the
right routine for that until all the disk changes are complete, so while
- this is a library only change, its likely one that will be delayed to near
+ this is a library only change, it's likely one that will be delayed to near
the end of the process.
* Add an explicit API for managing cached annotations. While annotations are
@@ -68,7 +68,7 @@
through review.
* Stop requiring full memory copies of files. Currently bzr requires that it
- can hold 3 copies of any file its versioning in memory. Solving this is
+ can hold 3 copies of any file it's versioning in memory. Solving this is
tricky, particularly without performance regressions on small files, but
without solving it versioning of .iso and other large objects will continue
to be extremely painful.
@@ -84,7 +84,7 @@
* Revision data manipulation API. We need a single streaming API for adding
data to or getting it from a repository. This will need to allow hints such
as 'optimise for size', or 'optimise for fast-addition' to meet the various
- users planned, but it is a core part of the library today, and its not
+ users planned, but it is a core part of the library today, and it's not
sufficiently clean to let us simplify/remove a lot of related code today.
Interoperable disk changes
@@ -104,7 +104,7 @@
* Repository disk operation ordering. The order that tasks access data within
the repository and the layout of the data should be harmonised. This will
- require disk format changes but does not inherently alter the model, so its
+ require disk format changes but does not inherently alter the model, so it's
straight forward to export from a repository that has been optimised in this
way to a 0.16 based repository.
=== modified file 'doc/developers/repository.txt'
--- a/doc/developers/repository.txt 2009-12-02 20:34:07 +0000
+++ b/doc/developers/repository.txt 2010-11-12 14:28:36 +0000
@@ -246,7 +246,7 @@
offset for the data record in the knit, the byte length for the data
record in the knit and the no-end-of-line flag.
-Its important to note that knit repositories cannot be regenerated by
+It's important to note that knit repositories cannot be regenerated by
scanning .knits, so a mapped index is still irreplaceable and must be
transmitted on push/pull.
=== modified file 'doc/developers/revert.txt'
--- a/doc/developers/revert.txt 2009-12-02 20:34:07 +0000
+++ b/doc/developers/revert.txt 2010-11-12 14:28:36 +0000
@@ -17,7 +17,7 @@
for the selected scopes, for each element in the wt:
1. get hash tree data for that scope.
- 1. get 'new enough' hash data for the siblings of the scope: it can be out of date as long as its not older than the last move or rename out of that siblings scope.
+ 1. get 'new enough' hash data for the siblings of the scope: it can be out of date as long as it's not older than the last move or rename out of that siblings scope.
1. Use the hash tree data to tune the work done in finding matching paths/ids which are different in the two trees.
For each thing that needs to change - group by target directory?
=== modified file 'doc/developers/tortoise-strategy.txt'
--- a/doc/developers/tortoise-strategy.txt 2009-12-02 20:34:07 +0000
+++ b/doc/developers/tortoise-strategy.txt 2010-11-12 14:28:36 +0000
@@ -437,7 +437,7 @@
* Implement property pages and context menus in C++. Expand RPC server as
necessary.
-* Create binary for alpha releases, then go round-and-round until its baked.
+* Create binary for alpha releases, then go round-and-round until it's baked.
Alternative Implementation Strategies
-------------------------------------
=== modified file 'doc/en/release-notes/bzr-2.3.txt'
--- a/doc/en/release-notes/bzr-2.3.txt 2010-11-12 09:37:34 +0000
+++ b/doc/en/release-notes/bzr-2.3.txt 2010-11-18 19:38:28 +0000
@@ -54,10 +54,17 @@
and display the definition sections when appropriate.
(Vincent Ladeuil, #671050)
+* Don't create commit message files in the current directory to avoid nasty
+ interactions with emacs (which tries to establish the status of the file
+ during the commit which breaks on windows). (Vincent Ladeuil, #673637)
+
* ``bzr resolve --take-other <file>`` will not crash anymore if ``<file>``
is involved in a text conflict (but the conflict is still not
resolved). (Vincent Ladeuil, #646961)
+* Merge will now correctly locate a lca where there is a criss-cross merge
+ of a new root. (Gary van der Merwe, #588698)
+
* Report error if non-ASCII command option given. (Rory Yorke, #140563)
Documentation
@@ -77,6 +84,9 @@
.. Major internal changes, unlikely to be visible to users or plugin
developers, but interesting for bzr developers.
+* ``BranchBuilder.build_snapshot`` now accepts parent_ids == [].
+ This can be used to create a new root in the graph. (Gary van der Merwe)
+
Testing
*******
More information about the bazaar-commits
mailing list