Re: Merging insanity

Ian Eure wrote:
> "Better" is a subjective term. I feel that it has significant issues
> which make it worse than CVS. And I am most definitely not suffering
> from "branchitis;" I've only created two branches.

Having not used CVS, I can't say if Subversion is "better". But I've
found it quite usable. The ONLY thing I've found troublesome so far is
the occasional need to type long-winded URLs - solved in part by setting
a shell environment variable or using one of several GUI interfaces
(which presumably store the repo URL somewhere internally).

> Perhaps instead of arguing over minutiae, someone would be kind
> enough to explain the usual way for using SVN in the following
> scenario:

I don't know about "the usual way" but I'll describe how I've been
working on a project here. I'll generalize a little (for instance, I
don't often use shell variables for the repo base URL - <Barbie> Dollar
signs are hard! </Barbie>. The project is a web-based system for
managing IP address allocations; it doesn't have any large files (where
by "large" I mean "over 500K"), so some of my methods might not work so
well for you.

> - There is a live setup for production, a staging setup for testing,
> and a dev setup for active development.

For my dev environment, I actually have 3 working copies - one typically
set on repository /trunk, one pointed to /branches/stable (where I keep
the current production code), and a spare for doing merge operations
without mangling work I might have on the go and in a state I consider
"uncommitable".

> - Major work is undertaken on the dev setup

To start a new major feature in my codebase, I do:

$ svn copy $REPOURL/trunk $REPOURL/branches/featurename

That gives me space to work and commit without breaking what's in /trunk
(which isn't *always* comletely functional, but I try to keep it that
way).

I will usually then svn switch my "main" working copy to that branch,
writing code and committing at rather irregular intervals:

$ svn switch $REPOURL/branches/featurefoo

For various reasons, I may switch back to /trunk occasionally and commit
a small thing there.

> - While major work is underway, minor changes may be necessary on the
> production setup

This is where my second working copy comes in; it's a checkout of the
code nominally in production. As I noted above, I keep this code in
/branches/stable in the repo. The "real" production system is also a
checkout of $REPOURL/branches/stable which I can svn update when I've
finished fully merging a new feature or just committing a bugfix into
it.

Bugfixes typically involve one or two lines to be changed in one file.
I have my development system set up such that I can keep browser tabs
open on each of the workspaces, and the "real" production system without
having to monkey with Apache configuration every time I have to switch
from feature development to debugging production code. Or rare occasion
I have to do the debugging on the production server; fortunately not
often.

I *usually* commit bugfixes to /branches/stable, then merge them back to
/trunk; I *rarely* merge them into feature branches. Sometimes I merge
the other way around; I notice something while merging a
newly-completed feature back to the trunk and push that bugfix forward
into the stable code from /trunk. Not consistent but I've gotten into
the habit of logging such merges explicitly: "merge bugfix from /trunk
r1234" or "merge bugfix from /branches/stable r5678". I don't use -m
for the commit message; I *always* let svn commit open an editor so
it's easier to enter multiline log messages.

> - After major dev work is complete, it's moved to the staging setup
> and tested

When I think a new feature is working correctly in its own branch, I'll
move to my third working copy. svn log --stop-on-copy tells me where
the branch was taken from /trunk, and I've only done a partial merge
once that I can recall. I check out /trunk, and then, based on the
revision the branch was created and (usually) the revision number for
the last commit on that branch (taken from the call to svn log):

$ svn merge -r112:456 $REPOURL/branches/featurename .

Which, if I've been careful, merges the new feature seamlessly with
/trunk. Occasionally, there are conflicts. I resolve those and make
sure the code is still working, then I commit that. I include a note
about whether the merge was clean or not in my commit message.

> - Bugs are discovered and fixed
> - Fixed code is moved to the live setup

This is where I do several different things. For some features, I've
just merged all changes from /trunk into /branches/stable. For others,
for whatever reason (not wanting other changes that I've applied to
/trunk in the meantime, for instance), I'll merge from the feature
branch. In both cases, I'll use pretty much the same procedure as
above.

All of this could be done with a single working copy, but between the
fact that I sometimes need to bugfix on the run while in the middle of
developing a new feature, and the fact that my development space tends
to get a bit messy (not to mention my 1M working copies <g>); I found
it simpler to keep multiple working copies pointed to various different
repo URLs.

Occasionally I will create a tag for some stage of code that I feel
should be noted a little more prominently; svn copy -r4321
$REPOURL/trunk $REPOURL/tags/tagname does that just fine.

-kgd

-- 
Get your mouse off of there!  You don't know where that email has been!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org