On Thu, Jul 01, 2004 at 09:38:56AM -0400, Juliusz Chroboczek wrote:
>
> David, this is very much open for discussion. I'll implement minor
> version checking when you agree with the general idea.
I like the concept, but I think the RepoRW/RepoReadonly distinction isn't
likely to be sufficient--it tries to do too much and succeeds at doing too
little.
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. At least it seems to me that that would be the benefit of
storing the version in the repository.
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. 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.
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 and the [String]
indicates any temporary changes that are supported in the repository
(intended primarily for development releases).
The RepoFormat structure could then be passed around to various functions.
Perhaps functions like write_inventory could check on their own what the
appropriate format is.
This could be used to deal with adding new patch types without breaking
backwards compatibility. Previously I would implement read support in one
darcs version, and then write support in the next. We could now implement
both read and write support at once, but unless users update their version
number, they'd not generate the new patch type, so their repository would
remain compatible with the old type.
So we'd need a
can_we_read :: RepoFormat -> Bool
and once smart_diff is able to create different new patch types, we'd need
to introduce a RepoFormat parameter for smart_diff, which would restrict it
to old types if the repo format doesn't allow the new types.
Similarly if replace were implemented now, we could make darcs replace fail
if the repo format doesn't either have "replace" in it's [String] or have a
sufficiently high version number.
And I'm imagining as far as format goes that the [String] would be space
delimited. Of course, it could be dash-delimited, which would be more
similar to the conventions used with version names. And in case it wasn't
clear, I'd interperet the [String] parameter as order-independent.
--
David Roundy
http://www.abridgegame.org
|
