On Thu, May 06, 2010 at 18:06:59 -0700, Simon Michael wrote: > I joined an interesting discussion on #darcs today; here's what I > proposed. I think this or something like it would be a good > direction to aim for. What do you think ?
I'd like to give a little more background to this discussion. I think
we all agree that the current situation is bad. It's not 100% clear
that we can/should do something about it. I think we should, but then
we have to decide on what.
Desired outcome:
- eliminate user confusion
- make it easy for users to know what the 'right' thing for them is
- make it easy to align user actions with darcs hacker intentions
(right now, we want everybody to be using a hashed format)
- cope well with future developments
What ails us: confusion over formats
------------------------------------
Ever since Darcs 2 was released two years ago (2008-04-07), we have been
struggling with widespread confusion over formats. This has cost us in
many ways
* users switching from darcs (cf. laconi.ca, now known as status.net)
* users refusing to upgrade their client
* users resisting format upgrades
* users upgrading unnecessarily (painfully, alienating *their* users)
I'm not saying that the confusion is sole cause for this pain, but it's
a major contributing factor.
Background
----------
There are three dimensions to consider
1. client support (darcs 1 vs 2)
2. repository format (hashed vs unhashed)
3. patch semantics (mergers vs conflictors)
Right now we have three format names:
--old-fashioned (>= 1.x, unhashed, mergers)
--hashed (>= 2.x, hashed, mergers)
--darcs-2 (>= 2.x, hashed, conflictors)
Cause for confusion: polysemy?
------------------------------
I think the confusion is due to two factors
1. "darcs 2" can either mean
* darcs 2.x clients
* conflictor-based patch theory
* the --darcs-2 format
2. "hashed" can either mean
* hashed repositories (--hashed and --darcs-2)
* the --hashed format
Or maybe the key problem is simply that repo vs patch compatibility are
orthogonal. We could slave one to the other, but that would be bad
because then we would not be able to do things like upgrade people to
a hashed darcs 1 format (which is one of our current objectives).
The orthogonality approach
--------------------------
The discussion started over a proposal I had to eliminate as many
double-meanings as we can exposing the orthogonality of hashed/unhashed
vs mergers/conflictors.
On IRC last night, I made a proposal along those lines. Simon and Zooko
helpfully pointed out a couple of flaws in it. My current proposal is a
modest modification which addresses some flaws (changing meanings,
multi-dimensional choice).
We would have three formats:
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.
This approach still has at least one flaw in it, which is that users
could interpret (darcs-1-hashed) to mean that the format is compatible
with darcs 1 clients. We could mitigate it with help text, but only so
much.
The encapsulation approach
--------------------------
Simon's approach is to hide the internal details and present flags which
answer user questions:
darcs-1
darcs-2-backward-compatible
darcs-2
What is also nice about Simon's approach is that it introduces a
plan for evolution...
> - a major darcs version may introduce a new repo format "darcs-n",
> and if
> this is not interoperable with the previous format, may introduce
> a second
> format "darcs-n-backward-compatible" which is.
And I also like the pros he pointed out, but...
> - clear for users
I claim this is the only one that's unique to this approach
And that
> - extensible into the future
> - does not change the meaning of terms we're familiar with
> - usability-wise, the current situation is a mess that will get worse
> without a cleanup like this
are shared by the orthogonality approach.
['Encapsulation' may be very abusively misused terminology on my
part, sorry!]
Eric's argument
---------------
I respect the position that Zooko and Simon hold, which is that users
should not subject to what are essentially implementation details.
As Zooko has once said, "No flux capacitors!" I agree with that. I also
agree with "Don't make me think!" I hear you...
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.
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.
I think the current orthogonality approach is a little bit more
flexible, and it's also a little bit more conservative (in the
sense that it runs less risk of hiding the wrong details).
Phew!
-----
Anyway, it's all about the users in the end. If you can find a way to
kill the confusion and make users always do the 'right' thing, I'm
interested. Simon's approach is a very nice start. Maybe it is the
right way and I'm just being needlessly worried. But maybe there's a
third way yet?
--
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
