[darcs-users] darcs repository format naming cleanup

[Nathan Gray]

On Fri, May 07, 2010 at 11:41:32AM +0100, Eric Kow wrote:
> But what I'm worried about this:
> 
>  A. Future development: introducing a third repository format: what if
>     the Darcs 2.x line introduces a mega-hashed repository format that
>     we want everybody to use?  This means your orthogonal choices would
>     be:
> 
>      * mergers vs conflictors
>      * unhashed, hashed, mega-hashed
>   
>     How would this fit into an encapsulation model?  Would we deny
>     mergers users the ability to use mega-hashed repos?
> 
>     The argument against this is YAGNI (You Ain't Gonna Need It).
>     Maybe that's all that needs to be said, but I still worry.
> 
>  B. Confusion over 'compatibility': Are darcs-2-bc repos compatible with
>     darcs-2 repos?
>     
>     No, but they're compatible with darcs-1 repos.  The current
>     encapsulation approach makes the client-compatibility question
>     crystal clear, but it does this by obscuring the
>     repo-interoperability question, which makes me nervous.

I think this is a key point.  Old-fashioned repositories that
have been upgraded to a hashed representation are not
interoperable with darcs-2 repositories, however, they are only
readable by darcs-2 executables.

This suggests to me that the format versioning and the executable
versioning need to be different: have a completely different
naming scheme.  And there are two parts to the format: the
semantics and the file structure.  Eric also pointed out that
which executable can read the format is another dimension.

What if each semantic is given a letter, and each structure is
given an identifier?

  a-zip    (>= 1.x, unhashed, mergers)
  a-hashed (>= 2.x, hashed,   mergers)
  b-hashed (>= 2.x, hashed,   conflictors)

If we wanted to add the oldest executable version that supports
the format as another dimension, we could have something like:

  1.a-zip
  2.a-hashed
  2.b-hashed

>  C. How this fits in with other commands (darcs get --lazy, darcs
>     optimize --upgrade)
> 
> So I'm not really sure what to do.  I don't think the current
> orthogonality approach is quite right (it still suffers from the
> confusion of darcs client versions), but I'm also nervous about the
> current encapsulation approach.

This is a really good discussion with some great ideas.

-kolibrie

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20100507/8071aa08/attachment.pgp>