[RFC] Vanilla checkouts in 2.2

[Martin Pool]

2010/1/13 Paul Moore <p.f.moore at gmail.com>:
>>    Paul> (Confused newbie point here) In what sense is that
>>    Paul> "readonly"? It's certainly possible to make changes in
>>    Paul> that branch.
>>
>> If you make changes to your mirror, you can't use it as a mirror
>> anymore, so in effect you keep it read-only for *you* but you
>> update it from upstream of course.
>
> OK, I see that. So it's a case of "don't do that".
>
> That's fair (to an extent) but I can easily imagine setting up such a
> mirror, then without thinking, trying out a "quick change" and once
> I'd done that, being left with a "broken" mirror. In that case, I'd
> quite likely pop up on this mailing list saying "I broke my mirror -
> what do I do now?" (And maybe it's easy to fix, but I'd still feel
> confused and a little frustrated).
>
> If I wanted a "readonly mirror", I think I'd be justified in assuming
> that when someone gave me instructions, the resulting mirror would
> either (a) be actually readonly, or (b) ignore/discard local changes
> when I pulled. On the assumption that neither of these is actually
> possible, I'd be happy to be told how to make a local mirror, and that
> I should simply *treat* it as readonly.
>
> Sorry - I know this is nitpicking. But Martin's comment really did
> make me think "hmm, I thought I understood that - did I miss
> something?" It's that sort of low-level confusion that makes it hard
> to gain confidence that my mental model is accurate. It's not that he
> was being unhelpful, or misleading, just that his set of assumptions
> (probably complete with an instinctive mental picture of how he'd have
> his filesystem laid out with a "mirrors" directory and local branches
> of those mirrors) don't match mine, in a way that makes his advice a
> lot less helpful to a beginner than he meant it to be.

As Vincent said, this is not so much "I want a physically readonly
mirror" but "I want a mirror that I'm not going to commit to."  In
Bazaar at present the answer is "make a branch and just don't change
it", and perhaps that's fine.   On the other hand as you indicate,
people may actually accidentally change what they thought was a mirror
and get into a confusing situation.

A feature that lets them get a mirror that is actually readonly, that
is strictly a mirror and no more, could have value to some users.
That doesn't necessarily imply that we need to build everything that
could possibly be useful, or that we need to do it right now or as
part of this analysis.  It was an example.

What I am trying to encourage is that in thinking about how branches,
etc work, we start from a description of the things the user is
actually trying to do and then see how they may to the proposed
solution.  Those won't necessarily map 1:1 to commands or features and
it's OK if we analyse some things and up end answering them with
"sorry you can't do that" or "you have to remember to X".

One of the other cases I gave (in a different thread was?)

  I have a team of dvcs-naive users who want to just check in changes
as they make them, all into a single branch, without thinking about
merging or pushing.

Other dvcs say "sorry you can't do that", which is a valid answer
though perhaps not optimal.  We let you use bound branches or
checkouts.  Coming back to just what we're trying to achieve may help
detangle just which solutions we want to offer.

-- 
Martin <http://launchpad.net/~mbp/>