[darcs-devel] darcs patch

David Roundy droundy at abridgegame.org
Sat Jul 3 06:09:06 PDT 2004


On Fri, Jul 02, 2004 at 08:25:34PM +0200, Juliusz Chroboczek wrote:
> > True, but your code added a distinction which didn't make any sense to
> > me.  I'm not sure there ever will be such a thing as a read only
> > format, and if so, it'll be the *new* version that can only read and
> > not write.
> 
> [...]
> 
> > >   - if the repo format changes in a semi-compatible way, bump the
> > >   minor version;
> 
> > I don't see this as being possible.  If we can read from a given
> > format, we can write to it.  Can you come up with an example where we'd
> > change the minor version?
> 
> Adding a new index file that must be kept in sync with _darcs/inventory.

Ah, that's a good point... it depends how we decide to do future repository
transitions.  My leaning was (and is) to avoid having multiple synchronized
formats in the same repository.  It's the way we did it before, but that's
because we had no (well, very little) versioning support.

I'd rather (when introducing an "inventory replacement") have the new darcs
able to read or write *either* format, and decide which to write based on
the repository version.  Then people who need to interact with users of old
darcs would use the old format, while others could test out the new.

> > Introduction of new patch types is going to be the first occasion on
> > which this format versioning becomes important, so we want to make sure
> > that it's at least useful for that.
> 
> Okay, I see your point.  Could you please outline a versioning scheme
> that you'd be happy with?  I'll be glad to implement it if I'm convinced
> it allows us full hacking freedom post-1.0.

I'm thinking (right now) that a format of the form

data RepoFormat = RF Int Int [String]
instance show RepoFormat where
 show (RF major minor as) = show major++"."++show minor++concatMap ('-':) as

where the [String] is restricted to contain no dashes, and really shouldn't
contain any spaces for aesthetic reasons.

Then when reading a repo (or checking a version on a repo--you can decide
when or where to do this), for the moment if there are any elements in
[String], we'll die with an error message explaining that we don't support
feature whatever.

I'm not entirely decided how we should treat the first and second Ints.  My
first thought was that the first would be a "format" version number, and
the second would be a "logical" version number--which would primarily
indicate the set of patch types supported.  This seems reasonable in some
ways, since patch types are far easier to backport than repo formats (for
example, a berkeleydb or SQL format), but the patch type aspect changes
more often.  If we did this, we'd only support reading from versions that
are known in both first and second digits, and we'd be constrained to take
the write-either format transition rather than the write-both format
transition route.  I think I'd prefer the write-either transition, so this
should be fine, but if you disagree, I'll listen.

If you wanted, you could replace the [String] internally with a
[FormatFeature] which wouldn't change the representation on disk, but would
centralize the location of feature checking into the repo format
parser--not a bad idea.  Eventually we'd have FormatFeature be something
like DarcsFlag, where one might check if BzippedPatches `elem` format, or
something like that.
-- 
David Roundy
http://www.abridgegame.org




More information about the darcs-devel mailing list