On Fri, May 07, 2010 at 06:00:58 -0700, Simon Michael wrote: > > darcs-1-unhashed (>= 1.x, unhashed, mergers) > > darcs-1-hashed (>= 2.x, hashed, mergers) (get default) > > darcs-2-hashed (>= 2.x, hashed, conflictors) (get/init default) > > > >We can either make these flags like --darcs-1-unhashed or arguments to a > >single --format flag, the choice of which I claim is not essential at > >this time. > > I think a single --format flag is the right ui and conceptual model, > because these are mutually exclusive alternatives.
That's fine, and I think I agree. Moreover we have a general ticket that advocates making this change for *all* our mutual exclusion flags http://bugs.darcs.net/issue1457 Not that this will happen for a while, but it's nice to know where we're thinking of heading. I just saw it as being a separate discussion to what I saw as the deeper issue of exposing the developer model to users or not. > > darcs-1 > > darcs-2-backward-compatible > > darcs-2 > > It sounds like we agree on describing repo formats at least > conceptually by simple names in a linear progression. And we differ > on what those names should be. It sounds that way. To compare: ===================== =========================== orthogonality-centric encapsulation-centric ===================== =========================== darcs-1-unhashed darcs-1 darcs-1-hashed darcs-2-backward-compatible darcs-2-hashed darcs-2 darcs-1-megahashed ??? darcs-2-megahashed darcs-3-backward-compatible darcs-3-megahashed darcs-3 ===================== =========================== "megahashed" is really just a made-up name for a hypothetical scenario, not something we actually plan on. So the approach on the left tries to maximise clarity in the question of "which repos are compatible with each other?" (any darcs-1 repo can share patches with any other darcs-1 repo, and any darcs-2 repo can share patches with any other darcs-2 repo) The approach on the right, on the other hand, maximises clarity in the question of "which darcs client can I use this repository with?" I don't know which is the right way. Because I have a developer-centered perspective, I much more prefer the approach on the left (personally). One argument I would make is that with respect to the issue of repo-format compatibility, the darcs-client compatibility question is a little bit ephemeral. One day in the future, most of the darcs 1 clients will be gone. So we might as well emphasise clarity on the questions that will remain long after darcs-1 clients are gone (and in the future long after darcs-2 clients have vanished too). But maybe I'm wrong. Maybe we need to focus all our clarity on the key transition points when one client starts to be superseded by another. A second argument is that misinterpretations about client compatibility are less grave than misinterpretations about repo compatibility because the former are eminently reversible (just darcs get into the old format), whereas the latter are not. > > * mergers vs conflictors > > * unhashed, hashed, mega-hashed > As a user, I would want darcs to make this choice for me, and just > do the best thing. Agreed, but I think that's also a separate issue. Darcs *already* makes this choice for you by virtue of --hashed being the default for darcs get, and --darcs-2 being the default for darcs init. And under any new scheme we introduce, Darcs will continue to make the choice for you by default. The issue is what to do with in the occasional situation where the best thing is to let the user decide. It's not always clear that users should use the very latest versions of everything, because these may be more experimental / less known than the older versions. If we introduce the hypothetical mega-hashed format, we would need to have a transition stage where users can *optionally* use it through conscious choice and then only in the future use it by default. > When that's not possible, I'd expect a new format > (darcs-3) introduced by darcs 3. Under my proposal darcs 2.x > wouldn't be allowed to add an incompatible repo format. (But if it > did, it would be darcs-2-mega-hashed, and --format would support it > just like the others.) To be clear, the idea is that darcs-2-mega-hashed repos can exchange patches between darcs-2-hashed repos. What we're missing in the encapsulation-centric approach is a name for what I'd call "darcs-1-mega-hashed" (which would be able to exchange patches with darcs-1-unhashed and darcs-1-hashed repos). > Back to the names - the problem is what to call the interim format. > Today, there's only one of those, which informally we call "hashed". > Of the alternatives we've discussed so far, I slightly prefer the > "darcs-2-backward-compatible" naming scheme; it can be > misinterpreted, but so can all the others. Yes. See above on my thoughts about what the misinterpretations are. > If we can't agree on this or a batter name, a more modest proposal > would be to punt the naming issue into the future, and stick with > --format=darcs-1|hashed|darcs-2. Ie, change the ui and conceptual > model to reflect (current) darcs users' reality, rather than > developers'. This too would be a step forward. Perhaps! Anyway, I think we're getting a little more clarity on the issue and we have a lot of common ground to build on, so I'm optimistic! -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9
signature.asc
Description: Digital signature
_______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
