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

[Tom Tobin]

On Fri, Aug 15, 2008 at 4:16 PM, Tom Tobin <korpios at korpios.com> wrote:
> At work, I just switched from using svn to bzr-svn to work against our
> Subversion repository.  (I already happily use Bazaar for everything
> else.)  I'm having a bit of trouble figuring out a sane workflow,
> though.

I thought I'd follow up with the workflow I ended up using:

# creation
bzr init-repo foobar
cd foobar
bzr branch bzr+ssh://some_svn_repo trunk
bzr co --lightweight trunk wc # short for Working Copy
# [rewrite local tweaks as to use new files not tracked by repo]
# [edit .bzrignore to add local tweak files and .bzrignore itself]
# [point servers/apps to the wc dir]

# hacking
cd foobar
bzr branch trunk new-feature
cd wc
bzr switch new-feature
# [hack hack hack]
bzr push ../trunk

# if I plan to use that branch again and don't want commits showing up twice:
bzr uncommit -2 # or -3, etc. as appropriate
bzr revert

# pushing upstream
bzr switch trunk
bzr dpush # see note below

# continuing to hack on same branch
bzr switch new-feature
bzr pull # made possible by earlier uncommit
# [hack hack hack]

The major hangup I have here is the way bzr-svn doesn't have a "do the
right thing" option for pushing and pulling; sometimes I'll dpush
first and it'll complain that I need to rebase first; sometimes I'll
rebase first and it'll complain that I need to pull instead.  Argh!
:-)  It would be great if both dpush and rebase had an option to
perform any necessary alternate operations automatically; there's too
much trial-and-error involved as things stand now.

(Perhaps I should also give bzr-loom a look, considering that nothing
above involves sharing branches; my workflow might be needlessly
messy.)