Rev 5534: Consolidated with devnotes. in file:///home/vila/src/bzr/experimental/config/

Vincent Ladeuil v.ladeuil+lp at free.fr
Wed Mar 30 13:13:29 UTC 2011


At file:///home/vila/src/bzr/experimental/config/

------------------------------------------------------------
revno: 5534
revision-id: v.ladeuil+lp at free.fr-20110330131329-n3oo738gfdaz42fd
parent: v.ladeuil+lp at free.fr-20110330130702-3fpded26cxyr4bk1
committer: Vincent Ladeuil <v.ladeuil+lp at free.fr>
branch nick: doc-new-config
timestamp: Wed 2011-03-30 15:13:29 +0200
message:
  Consolidated with devnotes.
-------------- next part --------------
=== modified file 'doc/developers/configuration.txt'
--- a/doc/developers/configuration.txt	2011-03-30 13:07:02 +0000
+++ b/doc/developers/configuration.txt	2011-03-30 13:13:29 +0000
@@ -56,10 +56,10 @@
 * Access to the 'active' configuration option value from the command line
   doesn't give access to the specific section.
 
-* Rules for configuration options are not clearly defined for remote branches
-  (they may differ between dumb and smart servers the former will use the
-  local ``bazaar.conf`` and ``locations.conf`` files while later will use the
-  remote ones).
+* Rules for configuration options are not clearly defined for remote
+  branches (they may differ between dumb and smart servers the former will
+  use the local ``bazaar.conf`` and ``locations.conf`` files while the later
+  will use the remote ones).
 
 * The features offered by the Bazaar configuration files should be easily
   accessible to plugin authors either by supporting plugin configuration
@@ -308,12 +308,12 @@
   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
-  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. As of today, the size of the configuration files
-  are small enough to be kept in memory.
+  constrained one shouldn't introduce any. Yet, in order to detect such racing
+  scenarios, we can add a check that the current content of the configuration
+  file is the expected one before writing the new content and emit warnings if
+  differences occur. The checks should be performed for the modified values
+  only. As of today (and in the foreseeable future), the size of the
+  configuration files are small enough to be kept in memory.
 
 The Config object
 -----------------



More information about the bazaar-commits mailing list