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
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
> - 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
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
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
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
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
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.
Get your mouse off of there! You don't know where that email has been!
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Sep 2 22:33:20 2005