Workflows, rebase, patch theory

[Russel Winder]

On Wed, 2008-05-07 at 15:54 +1200, Talden wrote:

> For this reason I wish that commits were local until released and that
> externals pulls and your pushes never passed local commits out of the
> local repo.  Therefore you can rebase and amend as much as you like in
> sensible parcels of changes.
> 
> Of course this immediately makes the quesiton of how you can locally
> backup more complex because you can't just push to one of your own
> clones.

Reading this thread, the following springs to mind:

There seems to be 3 classes of workflow here:

1.  Using a DVCS as a DVCS with or without a centralized master branch.

2.  Interworking DVCS and CVCS.

3.  Using a DVCS as a client to a CVCS or using a DVCS to replace a CVCS
but implementing an essentially centralized model.

In my particular case, I am using Bazaar for 1, Git or Bazaar as a
client to Subversion for 3 and I am not doing 2.

I can see that rebase (as I understand it) is anathema to 1 since it
discards history, and without history we are nothing.  For 3 though
rebase seems like the right thing to do.  The centralized repository is
the master and only  the history there matters, the client is being used
simply to make disconnected working viable.

Using Git as a Subversion client, I am using rebase (and stash) a lot to
ensure that the Git repository history remains a mirror of the
Subversion repository history.  I haven't yet sorted out in my head the
best way of doing the equivalent with Bazaar -- I haven't yet
experimented with bzr-rebase, and bzr-svn is really focused on 2 above,
a workflow that I don't use and am unlikely to.

In class 1 aren't commits always local anyway?  The branch is not bound
to another.  For me working in class 3, having local commits as the
default and uploading all commits as a batch job is the right way of
working -- it allows fine grain control over when the client interacts
with the server.  I am finding that the Git model of svn rebase, (edit,
commit)*, svn dcommit works very well.  This seems to map to Bazaar's
unbind, (edit, commit)*, bind, update, commit.  It is this latter part
that is awkward.

I think my point here is that bzr-svn is focused on class 2, where I am
using class 3 and the support needed for the two ways of working are
subtly different to make for intuitive use of the tools.

> I think that, with the Bazaar model of producing merge commits for
> bringing in non-conflicting upstream changes you do need to use rebase
> to keep history moderately reconsumable for longer term branches - and
> those are going to happen in many projects.
> 
> You almost want those merge commits to be annotated if they're the
> results of the automated merge process rather than any conflict
> resolution so you can abbreviate revision graphs - but of course this
> effectively records the merge algorithm itself in the commit which is
> undesirable.
> 
> --
> Talden
> 
-- 
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080507/ef647e11/attachment.pgp