When using get (without --to-match), darcs uses the _darcs/format file 
to  write into the new repo, instead of the one it just created.

Thus, if you have a repo with an _darcs/format like this:
hashed|invalid
darcs2

then darcs can't get it, while it should. darcs get --to-match "name .*" 
works ok in that case.

I don't quite understand this. Why is getting from format 'hashed|invalid' 
ever ok?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 02/11/2010 23:18, Ganesh Sittampalam a écrit :
> 
> 
> Ganesh Sittampalam <ganesh@earth.li> 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).

Florent
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzQlxQACgkQTCPcDztjGo70rwCeOrydsBRkOrDseKrb/galO00r
1ksAnjgXxaBjVeWZX74jr66IH+6HR6xD
=JrOO
-----END PGP SIGNATURE-----

Le 03/11/2010 00:00, Florent Becker a écrit :
> 
> 
> Florent Becker <florent.becker@ens-lyon.org> added the comment:
> 
> Le 02/11/2010 23:18, Ganesh Sittampalam a écrit :
> 
> 
>> Ganesh Sittampalam <ganesh@earth.li> 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.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> The convention of having lines that contain alternatives is abused at
> the moment we write things like "hashed|no-working-dir", since it does
> not make sense for a darcs client to understand "no-working-dir" and
> not "hashed". From the beginning we interpret "hashed|no-working-dir"
> as "hashed support is necessary to read, and hashed and no-working-dir
> support is necessary to write".
> 
> So, what about agreeing to interpret _darcs/format lines "A|B|..|X"
> as: A is necessary to read the repos, and A, B ... to X are necessary
> to write to it?
> 
I thought about it, but this means breaking compatbility: we'd have to
write it under _darcs/format2, and have _darcs/format be the single line
'format2'. The problem is that we cannot change how darcs 2.5 (or 2.4)
reads _darcs/format, so we cannot afford to have a "new semantics"
alternative with already known properties (for instance, no
darcs3|hashed). That should not be an insurmontable problem, given that
darcs 2.5 understands very few format strings, but it is bug prone.

Stupid question: does '|' ever appear in current repositories?

> This change of semantic could go into 2.5.1, in the same time that
> your "resolve issue1978" patch, to fix the "minced|no-working-dir"
> case.
> (The function Darcs.Repository.Format.readProblem would have to be modified).
> 
> Otherwise, keeping the current semantics of _darcs/format, I believe a
> variant of (c) would be the best solution by writing
> 
> minced
> minced|no-working-dir
> 
> Which sort of "encodes" my proposed semantics in the current
> interpretation of _darcs/format.
> 
I think this is the most elegant solution.

Florent
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzW7xcACgkQTCPcDztjGo4BrgCdG4AjaCBxCxcvI0MGTyrfc0uB
4jwAnAnuv6mSb8Q87WsXohYL5p4I5sqz
=k42D
-----END PGP SIGNATURE-----

>> So, what about agreeing to interpret _darcs/format lines "A|B|..|X"
>> as: A is necessary to read the repos, and A, B ... to X are necessary
>> to write to it?
>>
> I thought about it, but this means breaking compatbility: we'd have to
> write it under _darcs/format2, and have _darcs/format be the single line
> 'format2'. The problem is that we cannot change how darcs 2.5 (or 2.4)
> reads _darcs/format, so we cannot afford to have a "new semantics"
> alternative with already known properties (for instance, no
> darcs3|hashed). That should not be an insurmontable problem, given that
> darcs 2.5 understands very few format strings, but it is bug prone.

See below:

> Stupid question: does '|' ever appear in current repositories?

I believe not (although Eric should confirm). This is why I think
changing the semantics before we introduce '|' can be done.
We are lucky that the only darcs clients that exist (as of now) are ours.

So this is not a stupid question at all, this is THE question :-)

Guillaume

Hello Florent,

My 2 cents: I believe the bug belongs in how we interpret _darcs/format.

The convention of having lines that contain alternatives is abused at
the moment we write things like "hashed|no-working-dir", since it does
not make sense for a darcs client to understand "no-working-dir" and
not "hashed". From the beginning we interpret "hashed|no-working-dir"
as "hashed support is necessary to read, and hashed and no-working-dir
support is necessary to write".

So, what about agreeing to interpret _darcs/format lines "A|B|..|X"
as: A is necessary to read the repos, and A, B ... to X are necessary
to write to it?

This change of semantic could go into 2.5.1, in the same time that
your "resolve issue1978" patch, to fix the "minced|no-working-dir"
case.
(The function Darcs.Repository.Format.readProblem would have to be modified).

Otherwise, keeping the current semantics of _darcs/format, I believe a
variant of (c) would be the best solution by writing

minced
minced|no-working-dir

Which sort of "encodes" my proposed semantics in the current
interpretation of _darcs/format.

Guillaume

(CC'ing darcs-users since it's a high-level decision on the design of
Darcs repositories)

Here is the situation with _darcs/format:

* there is a defined semantics :
http://article.gmane.org/gmane.comp.version-control.darcs.devel/5393
* if we want to use this semantics for expressing that a repository is
without working tree, we will run into a problem when we have a new
kind of repositories : http://bugs.darcs.net/msg12892
* I proposed a change in the semantics :
http://bugs.darcs.net/msg12949 , http://bugs.darcs.net/msg12948
* but I'm not sure if it is really a good solution…

At least the change is harmless because as of now, Darcs is the only
Darcs client and never writes "xxx|yyy" in _darcs/format .

Why we should decide this change soon:
 * so that it can be put into darcs 2.5.1
 * the feature no-working-tree repositories depends on this and it
would be a shame to delay this because of lack of discussion

Guillaume

2010/11/8 gh <bugs@darcs.net>:
>
> gh <guillaumh@gmail.com> added the comment:
>
>>> So, what about agreeing to interpret _darcs/format lines "A|B|..|X"
>>> as: A is necessary to read the repos, and A, B ... to X are necessary
>>> to write to it?
>>>
>> I thought about it, but this means breaking compatbility: we'd have to
>> write it under _darcs/format2, and have _darcs/format be the single line
>> 'format2'. The problem is that we cannot change how darcs 2.5 (or 2.4)
>> reads _darcs/format, so we cannot afford to have a "new semantics"
>> alternative with already known properties (for instance, no
>> darcs3|hashed). That should not be an insurmontable problem, given that
>> darcs 2.5 understands very few format strings, but it is bug prone.
>
> See below:
>
>> Stupid question: does '|' ever appear in current repositories?
>
> I believe not (although Eric should confirm). This is why I think
> changing the semantics before we introduce '|' can be done.
> We are lucky that the only darcs clients that exist (as of now) are ours.
>
> So this is not a stupid question at all, this is THE question :-)
>
> Guillaume
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue1978>
> __________________________________
>

The following patch sent by Florent Becker <florent.becker@ens-lyon.org> updated issue issue1978 with
status=resolved;resolvedin=2.8.0 HEAD

* resolve issue1978 
Ignore-this: bee36780c2ca85778675e280c8aee1ac