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
signature.asc
Description: Digital signature
_______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
