Full files in changesets?

[Denys Duchier]

Robert Collins <robertc at robertcollins.net> writes:

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

of course, but full bidirectional inexact patches are not necessary to achieve
that aim.

> 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 think that your question contains an assumption that I am uncomfortable with:
namely that _you_ are responsible for creating and sending the patch for foreign
consumption.  I think there are different kinds of activities that may take
place:

  - EXPORTING: where indeed you prepare a particular delta in a form that allows
    others to use it, who either do not have access to your branch or do not use
    the same vcs as you.

  - IMPORTING: where someone using the same vcs and having access to your branch
    (in some form) wants to bring in some changes.

Those are quite different circumstances for which the most appropriate answers
are different.  Even within those two broad categories, one could imagine
various scenarii that would affect the most appropriate form of the delta.

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

One very sad thing about arch is that, on the one hand it introduced this very
compelling (sort of) "relational database" way of looking at the contents (and
chronology) of a branch (i.e. mapping from ids to file objects), and then it
threw it all away to mandate a dumb file system interface to it.

Of course, the dumb file system interface _is_ a database system of sorts, but
all queries have to be formulated in the form of a pathname, which is very
inconvenient and limiting, and does not lend itself well to the implementation
of smarter db backends.  Furthermore, arch does not usefully abstract the notion
of backend: so all the smarts have to be implemented in the main arch client
itself.  This is terrible design.

What I am advocating instead is to abstract the interface using the notion of a
smart revlib service that accepts high-level queries.  The first backend for
this service is easy to create: just use to the dumb server interface to answer
all queries.  This is a smart server whose code we already have and which
happens to run in the client.  But now you have the structure to support
high-level queries and to add new backends that hopefully provide better service
than the dumb backend.

I hope this makes some sense.

Cheers,

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