Figuring out a workflow (bzr-svn, local changes I never want to push upstream)

[Tom Tobin]

(I'm such a moron; I sent this directly to John instead of the list,
since I expected Gmail to actually be smart and understand "reply-to"
on a list means "send to the list".  ::sigh::)

On Sat, Aug 16, 2008 at 10:33 AM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
> I'm a bit unclear why you would have feature off of local, unless that is the
> only way to get it to work on your machine. As an aside, this feels like a
> fragile way to work, no matter what VCS you are using. My quick guess is that
> you are versioning a config file, rather than versioning a template for that
> config file. How would you do it if you didn't have bzr? Just have a locally
> modified file that you never commit? Anyway, to continue...

We're developing a bunch of applications, and some websites, based on
Django.  I'm changing a few settings in the config files to point at
resources/servers on my laptop rather than the production server; I'm
also commenting out a few lines in code that would complicate my local
environment (forcing me to install a second database server) and
really aren't necessary for 99.9% of development/testing.

In Subversion, I pretty much just never committed these files (unless
a change was made to them, in which case I had another awkward dance
to perform involving copying my local version to the side, copying
back in just the new changes, committing, and then moving my local
copy back).  This involved constantly having to explicitly "svn di
files-I-care-about", etc, which was quite annoying.  (I couldn't just
have svn ignore the files, since other changes to these files would
actually matter.)

> You periodically bring changes from trunk (bzr pull), and then you propagate
> them through your other branches. It seems you are using 'bzr rebase' for
> this? (replay my local commit on top of trunk, and ignore the old revision.)
> You then rebase your feature branch on top of your new local branch, and then
> cherry pick the tip back into trunk.
>
> I'm a bit curious about how the feature branch works, and if you are always
> cherry-picking the last commit, or multiple commits, or what. If you are just
> cherry-picking, why not just use merge rather than rebase. So the workflow
> becomes:

I've been hacking on the feature branch, and then using uncommit to
compress all the changes down to a single atomic changeset suitable
for pushing back to the svn repository.  I have to cherry-pick because
of the local changes being in history.

[snip workflow]
> locally you just use cherry picking back and forth between the 'trunk' branch
> and the feature branch. I don't really see why you need to go through the
> 'local' branch at that point.

You're probably right; once I branch from local to create the feature
branch in the first place, I suppose I can ignore it (until I want to
branch another feature branch, at which point I'd rebase).

> It would be helpful (at least for me) to have a more concrete use-case
> defined. Of what changes are actually where, and what workflow you would like
> to see when you are done. And how tolerant you are to 'cheating'.
>
> For example, one of the really nice things about the current bzr-svn
> integration, is that you can have *multiple* people all using bzr
> synchronizing through the svn repository. If they have the extra bzr
> revisions, everything "lines up". (And 'multiple people' can also be a single
> developer working in multiple locations, eg desktop, laptop, server.)

I'm trying to introduce Bazaar to my co-workers, and they seem
somewhat receptive; if they started to seriously use it, I think we'd
simply do a one-shot conversion of out repository and only use bzr
going forward, so this wouldn't be a concern.  In the meanwhile, no
one else is using my local Bazaar branch; it's just for my convenience
making feature branches isolated from one another.

> That said, if you aren't trying to scale to those sorts of problems, there are
> lots of tricks you can do locally. Like having a combined bzr *and* svn
> checkout. So you would have 2 'branches' co-located in 'trunk'. One would be a
> bzr branch that follows the svn branch, but also tracks all of your local bzr
> branches.
[snip]
> This is a *much* simpler thing to implement that what 'bzr-svn' does. You can
> even have helper functionality for brining in multiple svn commits as bzr
> commits. Effectively they would be "rebased" from svn => your bzr branch.

I've actually done this before under Mercurial, and it worked, but was
fairly messy; I'd hate seeing all the ".svn" directories littering my
clean Bazaar branch (just in normal listings; I'd have it ignored by
bzr).  ;-)  But if that's the most sane path for the time being, it
might be worth another look.

> The main downside of this is that you only have 1 master bzr branch. Everyone
> who wants to work on bzr needs to be using *your* bzr trunk branch. (As
> opposed to bzr-svn where everyone who pulls from svn => bzr gets identical
> copies every time.)
>
> But if you are a "lone-wolf" there are much easier ways to get what you want,
> and not lose any of bzr flexibility.

Yeah, as per above, I can get away with this since we'd step directly
from "lone wolf" to "whole hog" (a permanent conversion) if anything.
I'll give it a shot.

Thanks for the feedback, John and Russel!