~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/yaml.txt

First programmatic generation of completions.

The list of commands is generated, as is the list of possible switches for
each command. Commands requiring arguments aren't treated specially yet.

For every option name there is a list of switches, and if any switch for the
option is given, then the others will be suppressed.  This might be
incorrect in some cases, but closely mimics the old, static function.  The
list of these switch suppressions might be incomplete, as some switches
might have different alternative forms for different commands, in which
cases only the intersection of all alternatives gets suppressed.  A future
version might do this suppression based on the current command, or drop it
completely.

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
YAML
2
 
****
3
 
 
4
 
I am thinking about keeping changeset headers in YAML_, as a nice
5
 
tradeoff:
6
 
 
7
 
 * Standard data format, so we don't need to invent, write and debug
8
 
   an ad-hoc format.
9
 
 
10
 
 * More concise than XML, which is useful if we're storing a few.
11
 
 
12
 
 * Reasonably readable for humans; thus suitable for sending in email
13
 
   and giving people at least some chance to read and understand it.
14
 
   Seeing this at the top of a patch would not be actively horrible as
15
 
   long as we keep it reasonably small; that's not true for XML.
16
 
 
17
 
 * Since YAML documents have a document header and terminator ('---'
18
 
   and '...') we can pick them out of a text document and append
19
 
   text patches directly afterwards.
20
 
 
21
 
 * Fits well with Python internal data structures.
22
 
 
23
 
 * There are parsers for various languages, so people can write their
24
 
   own implementation if they really want.
25
 
 
26
 
 * There is space to specify a document format/version at the top
27
 
   (though this is not currently handled in ydump).  
28
 
 
29
 
The ydump module is pretty primitive, but it should have enough.
30
 
 
31
 
.. _YAML: http://www.yaml.org/
32
 
 
33
 
 
34
 
Conclusion
35
 
----------
36
 
 
37
 
On the whole, I think this is not a good idea.  It is a nicer syntax
38
 
for XML, but there are less bindings, and it does not achieve the goal
39
 
of having the storage format look reassuring and giving confidence
40
 
that the data could be retrieved by an alternative implementation.
 
 
b'\\ No newline at end of file'