← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/compared-codeville.txt

  • Committer: Robert Collins
  • Date: 2005-10-29 23:48:45 UTC
  • Revision ID: robertc@robertcollins.net-20051029234845-7ae4e7d118bdd3ed
Implement a 'bzr push' command, with saved locations; update diff to return 1.

    * 'bzr diff' now returns 1 when there are changes in the working 
      tree.

    * 'bzr push' now exists and can push changes to a remote location. 
      This uses the transport infrastructure, and can store the remote
      location in the ~/.bazaar/branches.conf configuration file.

    * WorkingTree.pull has been split across Branch and WorkingTree,
      to allow Branch only pulls.

    * commands.display_command now returns the result of the decorated 
      function.

    * LocationConfig now has a set_user_option(key, value) call to save
      a setting in its matching location section (a new one is created
      if needed).

    * Branch has two new methods, get_push_location and set_push_location
      to respectively, get and set the push location.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/compared-codeville.txt
67
67
 
68
68
----
69
69
 
 
70
Rather than storing or calculating annotations, we could try using a
 
71
complex weave, which allows one file version to be represented as a
 
72
weave of multiple disjoint previous versions.  It sounds complex but
 
73
it might work.
 
74
 
 
75
Essentially we store each file as a selection of lines that should be
 
76
turned on in that file.  These files might come from any of the
 
77
predecessors that were merged into that file.  Complex to get right
 
78
but it might work.
 
79
 
 
80
This is written in terms of lines, but it might make more sense to
 
81
just use byte ranges: perhaps more efficient when handling long files,
 
82
and makes binaries less of a special case.
 
83
 
 
84
codeville in fact does *not* seem to do this, though to me it seems
 
85
like a fairly natural corollary of their design.
 
86
 
 
87
This seems to imply holding the file text and ancestry of every branch
 
88
that ever merged into this one, rather than just finding them if we
 
89
later want them.  Hm.  That is nice in terms of doing smart merges.
 
90
That possibly causes trouble in terms of having a name for these
 
91
branches floating around inside our space, and making sure we don't
 
92
clash with them.  It may make sense in terms of having a working
 
93
directory be just a view into a shared database, looking at a
 
94
particular line of development.
 
95
 
 
96
Indeed the main difficulty seems to be of naming branches in this
 
97
space.  Perhaps we should move back to using repositories and named
 
98
branches within them, but not rely on branch names being unique out of
 
99
the context of a single repository.
 
100
 
 
101
Wow, this seems to open a big can of worms.
 
102
 
 
103
----
 
104
 
70
105
So the conclusion is that this is very cool, but it does not require a
71
106
fundamental change of model and can be implemented later.