> Oh, and I'd prefer to call it RepoFormat rather than RepoVersion... since
> the format should become decoupled from the darcs version as much as
> possible.
No objection if that's what you prefer. Do you want _darcs/version to
become _darcs/format?
> What I'd like to see (and I haven't figured out how this will work) would
> be something where we could (eventually) write to multiple repository
> formats AND read from multiple formats.
Let us please distinguish between the implementation (which we can
change at a whim) and the on-disk format (which needs frozen before
1.0).
The implementation can be done later. For now, it's enough to make
sure that the version is checked, so that we can bump the version
later (and implement any form of smart parsing of _darcs/version)
without fear of having older versions of darcs break without a
newbie-friendly error message.
Note in particular that I'm not reading anything beyond the first line
of _darcs/version; I expect the lines after the first one to contain a
list of optional format features (``extensions'').
---- _darcs/version ---
1.0
AUTHOR_GPG_KEY 1.2
BZIPPED_PATCHES 1.0
STICKY_PREFERENCES 1.0
-----------------------
The plan is:
- if the repo format changes in an incompatible way, bump the major version;
- if the repo format changes in a semi-compatible way, bump the minor
version;
- if the repo format changes in a compatible way that for some
reason requires noted, add a new extension name after the first
line of _darcs/version.
> We may be more likely to be limited in the formats that we can read
> from than in those which we can write to. In your current scheme,
> formats we can read from are forced to be "unknown", which may not
> be the most useful way of looking at it.
Er, no. Formats we can read from are Readonly, Unknown format are
those we can neither read nor write.
> I'm imagining something like an abstract type (i.e. not exported):
>
> data RepoFormat = RepoFormat Int Int [String]
>
> where the first Int indicates the format of the repository as a whole, the
> second indicates the set of patch types supported
Patch format should be noted in patches, not in the repo itself. What
happens if I use darcs 59.0.3 and send you a patch which you try to
apply using darcs 13.8.2?
Versioning patch formats is the next step, I'll come to that when we
agree on the repo format versioning (as opposed to patch format
versioning).
> and the [String] indicates any temporary changes that are supported
> in the repository
The on-disk format handles that already -- your [String] are the lines
after the first one in the _darcs/version file. I just don't see any
point in bothering to parse them until we need the functionality.
(I'd actually expect them to be [(String, Version)], but that's a
detail.)
> This could be used to deal with adding new patch types without breaking
> backwards compatibility.
As noted above, patch format needs to be noted in the patch itself, or
else you break send/apply.
Juliusz
|
