[RFC] Vanilla checkouts in 2.2

[Paul Moore]

2010/1/13 Martin Pool <mbp at canonical.com>:
> 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.

I appreciate that - and thanks for the clarification.

> 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".

Agreed. That sounds like a good approach. Ideally, these should come
from (actual or potential) users, rather than from the development
team. Collecting such data is never easy, of course :-)

> 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.

That's not useful to me, but I can see that it's relevant to some people.

> 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.

OK.

>  Coming back to just what we're trying to achieve may help
> detangle just which solutions we want to offer.

On that basis, I'll offer my use cases. I'd characterise myself as a
casual user, working alone most of the time but with occasional
non-committer interest in larger projects.

1. Put a personal project under version control.Very little branching,
but I relatively frequently switch machines while working, so I do a
lot of committing to a shared repository (either a USB stick or a
public service like bitbucket of Google code).

2. Quickly grab a copy of a public project like Python. Sometimes just
for investigation (so it's read-only) but sometimes I'll develop a
patch in my copy (or in a branch based on my copy, so I can keep up to
date with the project trunk while working) and want to prepare it for
submission upstream (probably in the form of a patch, rather than a
DVCS-specific form like a merge request or a repo to pull from). I'm a
dabbler (and as I said, I work on a number of machines), so
maintaining a long-term mirror isn't a sensible option for me.

Because my working environment varies so much, I don't tend to
maintain an organised directory structure. Each "bit of work" just
gets dropped in a directory of its own under my personal "Work"
folder. For long-term projects I'll use something like Google Code or
Bitbucket. These projects are technically public, but in all honesty I
don't expect 3rd party contributions.

Oh - and I'm a Windows user, but pretty much exclusively command-line
based. Tools like TortoiseBzr and Bazaar Explorer are of no interest
to me.

I guess that little lot must put me in a minority of one!

I hope this is of some use.

Paul.