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
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
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.
84
codeville in fact does *not* seem to do this, though to me it seems
85
like a fairly natural corollary of their design.
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.
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.
101
Wow, this seems to open a big can of worms.
105
70
So the conclusion is that this is very cool, but it does not require a
106
71
fundamental change of model and can be implemented later.
added
removed
doc/compared-codeville.txt
