[darcs-devel] upcoming 0.9.22

[Juliusz Chroboczek]

DR> But hopefully 0.9.22 will be pretty good, and then perhaps I can
DR> start doing release candidates for 1.0.

If darcs is a serious software project (as I think it is), and not
just an experiment, a 1.0 release will need to guarantee upwards
compatibility of the repository format for ever and ever.

Because of that, may I suggest three changes to the repository format
that should be done *before* 1.0 is out?

1. Version the repository; put a file _darcs/version, the first line
of which contains the string 1.0, and all further lines are ignored
(they might be used for marking optional extensions in the future).
Darcs should accept to write to a repo only if the version is 1.0, and
accept to read but not write to a repo where the version is 1.whatever.

2. Allow including arbitrary metadata in patch files.  I think that
metadata should be in the form of an a-list of string tokens (I'll let
you define the format, I suggest allowing the same characters as in
Haskell identifiers plus the dash `-') associated to arbitrary
strings.  For example, this could be used for storing a human-readable
date in the committer's timezone, or the location of the repository
the patch originates from, or the CVS or GNU Arch changeset that the
patch was converted from.

For now, I suggest simply ignoring this extra data on reads, and never
writing it; when we work out what it is useful for, we'll work out how
to deal with it more reasonably.

3. Allow including arbitrary metadata in the _darcs/inventory file.
This is less essential, but might be useful if it turns out that some
metadata is used too often to be kept in the patches files only.

As far as the implementation goes, all that is needed is:

 - have initialize write the _darcs/version file;
 - have all commands check the _darcs/version file;
 - have the patch parser ignore the metadata area;
 - have the inventory parser ignore the metadata area.

Just doing that will allow us to stick with the current format for the
foreseeable future.

                                        Juliusz