Full files in changesets?

[Denys Duchier]

Aaron Bentley <aaron.bentley at utoronto.ca> writes:

> Currently, bazaar-ng doesn't have a changeset format.  If we're planning
> on adding one, it would be for code exchange, and wouldn't be used by
> the text store, as in Arch.

I fully agree.  This is a design decision which I really didn't like in arch:
recording the sequence of changes within one branch's chronology and exchanging
information between branches are different activities for different purposes
with different requirements.

> The knock-on effect is that you reduce the number of operators.
> Everything is a three-way merge-- there's no 'exact patching'.

It was also my feeling that 3-way merge is probably the most useful operator,
which means that changesets à la arch are essentially useless for exchanging
deltas sideways.  I also don't think it is a good idea to mandate a dumb server
format into the vcs.  This is why I suggested a separate notion of a "revlib
service": i.e. an abstraction that provides convenient access to a branch's
revisions (convenient in terms of the operations that the vcs needs to perform,
like 3-way merge).  It would be able to dynamically accommodate any number of
backends.  There is always the option of the dumb-arch backend that builds a
revlib on-demand, or the dumb-bzr backend that uses the .bzr/*-store
representation; but any number of other options could easily be added, e.g. use
of subversion-fs, access to a remote smart-server, or whatever.  The point is:
if you look at this way, you are not locked into one specific design decision.

just 2 cents of my not so reliable opinion ;-)

Cheers,

-- 
Dr. Denys Duchier - IRI & LIFL - CNRS, Lille, France
AIM: duchierdenys