What kind of workflow do I need?

[Robert Widhopf-Fenk]

On Saturday, January 26, 2008 at 03:58:50, Nickolay Savchenko wrote:
> Hi.
> 
> I've read about bazaar workflows, but I don't know what kind of  
> workflow do I need.
> 
> I have such situation: I develop web sites alone, so I need to have
> 2 branches -- server branch and development branch. Server branch
> should be optimized to run in production environment, development
> branch should be optimized for developing and testing new features.
> 
> So I need the following:
> 
> 1. Ability to backport some features from development branch to
>    server branch.
> 2. Ability to mirror working tree of server branch from development
>    computer to server.
> 3. Merge bugfixes in server branch to development branch.
> 
> The main problem is that I have no experience with DVCS (I've used
> subversion before, but I don't like to setup svn server every time I
> need to develop some small project)

You do not need a new svn server for each project, you could
also use one for all, just place each project in its own
directory within the svn repo.  You are probably aware that
with svn you currently have to track merges by hand, which
is a PITA.  What they call branches are IMHO just good for
creating tags.

Anyway, I still like svn for is speed on Windows, bzr feels
like a tortoise while not having the solid and nice
interface of TortoiseSVN.  Eclipse integration by BzrEclipse
became better, but it is still not the same nice experience
as with Subclipse.

I am curious if bzr will catch up with frontends, speed and
tools integration before svn gets merge tracking.  Also I
wonder if svn will do merge tracking right.

> , so I cannot find the optimal
> way to organize my workflow. Any advice and experience sharing would
> be very welcome! Maybe I should have more than 2 branches? I really
> don't know how to get started with bzr.

Start with the server branch "S", i.e. clean it up and then
"cd S; bzr init; brz add; bzr commit -m 'initial import'".

Branch the development branch "D" from the server branch,
i.e. "bzr branch . ../D".

Mirroring a branch is a "bzr push LOCATION" (or "pull" when
executed on the remote site by cron or the like) as long as
the branches have not diverged.  Use --remeber as option once
and you do not need to give the LOCATION anymore.

Merging bugfixes from "S" to "D" is a "cd D; bzr merge ../S;
bzr commit" ... merge can also remember the location.  There
might occur conflicts which have to be resolved before you
can commit.

Backporting is usually cherry picking, i.e. a merge of a
range of revisions, i.e. "cd S; bzr merge -rA..B ../D".
Unfortunately, cherry picks are not recorded by bzr for
now. 

You might be able to avoid cherry picking when planing
ahead.  Creating a feature branch for each new feature and
merge that branch into "S", this works best if you branch
the feature branch from "S" and merge it back into "S".
Before starting a new feature check if it depends on changes
in "D", if not base it on "S".

Before I had a VCS with proper merge tracking I never used
feature branches, but now I really like them.

Robert