Full files in changesets?

[Robert Collins]

On Mon, 2005-04-18 at 19:09 +0200, Denys Duchier wrote:
> 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.

I agree with this. As a side note, archs design decision was based a) on
allowing long term reverse engineering of the archive in the future and
b) an append only archive format that doesn't rely on the ability to
alter existing files incrementally.

> > 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.  

simple patches and three way application are directly transformable from
one to the other, as long as you have the basis available. Is it better
to send a file that may not be present in the common history, or require
that the reciever choose the base ? 

> I also don't think it is a good idea to mandate a dumb server
> format into the vcs.  

While I agree with abstracting out the interfaces for the various
operations, dumb server support places some significant constraints on
any vcs system. There is a huge different between mandating one, and
mandating that one can be efficiently operated. Arch mandates the latter
- and only provides the former. Its certainly possible to rip out the
dumb server support from arch and use a smart server end to end. I think
bearing in mind the requirements of a dumb server is very important -
many folk do not have their own web servers and rely on ISP's to provide
disk space - many users of Arch that have got past the appalling aspects
of it, did so precisely because no server support was needed.

> ...  The point is:
> if you look at this way, you are not locked into one specific design decision.

As long as the design does not require something that can only be
provided by a smart server!

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050419/6d2d1a12/attachment.pgp