tortoisebzr-developers team mailing list archive

[John Arbash Meinel <john@xxxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 :)
> 
> Thanks,
> 
> Mark

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

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

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

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIrCUGJdeBCYSNAAMRAhn5AKC0KYm091dSTKbPKFqCawe6IuGCkwCfbvEB
Mh1ae9od8XuyVonhntQGjA8=
=IVq1
-----END PGP SIGNATURE-----