Rev 5539: Merge 671050-config-policy into 672382-list-values in file:///home/vila/src/bzr/experimental/config/
Vincent Ladeuil
v.ladeuil+lp at free.fr
Thu Nov 18 19:38:28 GMT 2010
At file:///home/vila/src/bzr/experimental/config/
------------------------------------------------------------
revno: 5539 [merge]
revision-id: v.ladeuil+lp at free.fr-20101118193828-d9erh6rqr7d25gp7
parent: v.ladeuil+lp at free.fr-20101117155203-xoeu3g6x9jt1wsin
parent: v.ladeuil+lp at free.fr-20101118193826-c9si4fnq1gw6ybx8
committer: Vincent Ladeuil <v.ladeuil+lp at free.fr>
branch nick: 672382-list-values
timestamp: Thu 2010-11-18 20:38:28 +0100
message:
Merge 671050-config-policy into 672382-list-values
modified:
bzrlib/branchbuilder.py branchbuilder.py-20070427022007-zlxpqz2lannhk6y8-1
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_merge.py testmerge.py-20050905070950-c1b5aa49ff911024
bzrlib/tests/test_msgeditor.py test_msgeditor.py-20051202041359-920315ec6011ee51
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/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_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/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