John Arbash Meinel
john at arbash-meinel.com
Wed Aug 20 15:07:02 BST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Mark Hammond wrote:
> Alexander writes:
>>> Maybe there should be a generic "Update" item that "does
>>> the right thing"?
As always, the main problem is defining what the "right thing" is.
> Note the general confusion between people who you would expect would know (obviously including me). Note that last comment - it makes me concerned that, eg, exposing 'pull' on the default context menu of a checkout might be asking for trouble.
> So while there is a use-case for using pull on a branch, is it a use-case Tortoise needs to cover? This isn't a rhetorical question - I'm searching for the answer - or failing that, the most suitable middle-ground :)
Getting the model right for TBZR is a big deal. And certainly we need to
decide on something for a first round, and see if it works, and possibly tweak
I would be hesitant to make TBZR too minimal, at the expense of not actually
allowing people to work the way they want to. TBZR is likely to become *the*
face of bzr on windows. And it would be good to play to our strengths. I'm
including the bzr mailing list, because I think this is a big enough deal to
warrant lots of people looking at it.
The best way I can think of, is to define specific models of workflow. And
either allow TBZR to be set up explicitly in each model, or to have it
configurable per project, or have them as separate menu entries, etc.
To give some examples:
1) Windows developer with minimal VCS experience, in an office, working in a
shared environment with high-speed access to the central server. I would have
two recommendations here:
a) A lightweight checkout model, very similar to how svn would work. The
'branch' command would create a new branch on the remote server, and
switch, etc would be used to point their local working tree around.
'merge' is still necessary as they will want to create feature branches
and merge them back into trunk. It would probably be a second-order
command, but at the same level as 'branch'.
'update' and 'commit' would be the most common. It somewhat encourages
developing directly on "trunk", but that is the way it goes for people
with minimal experience.
b) A local treeless repository, with bound branches to the remote
repository, and a single (or small number) of lightweight checkouts.
This is very similar to (a) except it is for laptop users. So when they
disconnect from the local network, they still have access to history.
In essences, their local repo is simply a mirror of the shared repo.
'branch' would do double duty (create a remote branch, and a local bound
branch of the remote branch.)
'update' and 'commit' are still the most common. 'branch' and 'merge'
are second level. 'push' and 'pull' are third level. probably 'bind' and
'unbind' would also fit in the 3rd tier. If you go offline, you'll want
to be able to commit, and then push your changes back to get back in
2) Open source developer, tracking an upstream project.
a) With commit rights and no gatekeeper
This could work as (1b), but more likely they have slow connectivity to
upstream, so I'm giving an alternate here.
Local shared repository, with a bound branch of trunk.
I would recommend at least 2 working trees, one for trunk and one for
whatever feature branch is being worked on.
'branch' then creates a new local branch.
'update' is used on the trunk, but very infrequently anywhere else
'push/pull' might be a bit more common, as they start publishing their
'merge' becomes very important, to bring in upstream changes, and
probably to merge their changes into trunk.
b) With a gatekeeper (like PQM)
I would probably still recommend something like (2a) only the trunk
branch is now to a readonly location. And rather than merging into trunk
and committing, they need 'send'/'pqm-submit' etc.
We haven't discussed at all how we might have plugins include more
commands into the TBZR framework, but I certainly think it is something
we will want.
c) Without commit rights
Off-hand this feels the same as '2b'. You want a copy of the upstream
branches. I would recommend using bound branches for them.
Unfortunately, 'update' isn't quite right for a treeless branch, though
IMO it is the right command to use. 'bzr update' presumes you have a WT.
You'll want your own local branches (at least one).
You may want a loom for your work, which hasn't been discussed yet.
I've personally found that multiple local treeless branches and 'switch'
works quite well for a 'loom-ish' workflow. But it doesn't give you as
much tool support as real looms would.
d) Upstream is not in bzr
Integration with bzr-svn or any of those could be a *really* nice
feature. This may even fall under a (1c) category of a windows
developer, who is working on a laptop to an SVN repository, and wants to
have offline commits, log and annotate.
Anyway, I'm mostly just trying to define *why* bzr is flexible, and help
generate ideas of how we can allow that flexibility without overwhelming the user.
Obviously I'm also very partial to having a local shared repo for pretty much
everything. And using treeless branches would be my recommendation.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar