Le 03/11/2010 00:00, Florent Becker a écrit :
>
>
> Florent Becker <[email protected]> added the comment:
>
> Le 02/11/2010 23:18, Ganesh Sittampalam a écrit :
>
>
>> Ganesh Sittampalam <[email protected]> added the comment:
>
>> I don't quite understand this. Why is getting from format 'hashed|invalid'
>> ever ok?
>
> known|unknown is supposed to be a format darcs can read. Currently, you
> can do 'darcs get --match "blah"', or 'darcs init' + 'darcs pull' on
> such a repo, but not 'darcs get'. You won't be able to 'darcs push' to
> it, but you can 'darcs send' patches (I think).
>
From a discussion with Ganesh on irc, it seems that the semantics of the
_darcs/format is not clear. Here is a clarification that:
-is compatible with what's already been used
-corresponds to what's being checked in the tests in this bundle
-corresponds to the comments in Darcs.Repo.Format
-corresponds to what's done by darcs pull/push/apply and get --match
-but not to what's done by darcs get
-is most useful for future format modifications.
Here it is:
1. A format file is made of lines
2. Each line represents an (orthogonal) trait of the format
3. Each trait is of the form: variant_1 | … | variant_n
4. We can read a trait if we know at least one of its variants
5. We can write to a trait if we know all of its variants
6. We can read from (resp. write to) a repo if we can read from (resp.
write to) each of its traits.
Under this clarification, it seems that adding a 'dummy' trait would be
useful. In the current state, adding orthogonal features that are read
compatible is awkward: for instance, working-dir-less repos use
hashed|no-working-dir. This means that when "minced" repositories are
implemented in darcs 2.10, a minced no-working-dir repo is going to have
a format file with minced|no-working-dir, which is going to be readable
by darcs 2.8.
This is a bug in waiting. The solutions are:
(a) drop all this _darcs/format non-sense and do what camp does (have
the compatibility matrix be computed before writing into the format
file, which reads as: "readable by darcs 2.0+, writable by darcs
2.12+")
(b) add a "dummy" trait, which is known as of darcs 2.5.1 that is used
for variants that don't affect readability. In that case, a hashed
working-dir-less repo's _darcs/format looks like:
hashed
dummy|no-working-dir
and the minced version looks like:
minced
dummy|no-working-dir
(c) use "hashed" as that dummy trait for compatibility with darcs 2.0+.
This means that a working-dir-less minced repository looks like:
i. minced
hashed|no-working-dir <--- This is a lie
Or even:
ii. minced
not-at-all|hashed|but-still|no-working-dir
(d) assume that support for features is monotonic, and have the
working-dir-less minced repository look like:
minced
no-working-dir
(a) and (b) are clean but mean that we introduce yet another
compatibility breakage. (c) is not that clean, but some variant of
(c).ii can reduce the wtf factor. (d) is clean and compatible but means
no (format affecting) plugins and writing _darcs/format becomes
ultraviolet magic.
My vote is (c), especially if we can find a cute variant of (c).ii
What do other think?
Florent
PS: Public programming hygiene announcement: *always* put a noop in your
language.
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
