On Wed, Mar 10, 2004 at 05:45:16PM -0500, N. Thomas wrote:
> I don't do it as often as once per day, but every time I add a new
> feature to the code that I'm working on, I will branch, do the write,
> compile, test, commit cycle a bunch of times and then merge back into
> the trunk, deleting the branch when I am done. (This is for a personal
> project of mine, but I suppose if I were working on it full-time, and I
> had enough bite-sized features, then I could imagine myself branching
> more often.)
So you are using the "Task Branch" pattern (branch per task/feature).
Have you considered the "Private Branch" (a.k.a. "Personal Branch")
pattern of using a branch per developer per active/concurrent
feature or task?
So if you primarily work on one task at a time, you have a
single branch all to yourself. When you are done with your
change (and after you have "updated" from the main trunk)
you "commit" your change to the main trunk. And instead of
deleting or obsoleting the branch (its not needed for change-set
purposes) you use it for the next task you are about to start
work on (because it should be the same content as the main
trunk at that time). And you don't create a new "private branch"
unless you have to work on some other task in parallel with
what you are currently working on in your initial private branch.
Seems to me this still provides you the folllwing benefits,
but with far fewer branches/copies needing to be created.
> Two nice things about doing it this way:
>
> - the trunk always has the features I want fully implemented and is
> never in a state of unfinished, partly-working/partly-broken
>
> - I can work on adding multiple components to my system this way by
> putting them all in separate branches. It would be terribly
> confusing if I were to do it all in the main trunk.
The main reason why folks would do a Task-Branch instead of a
Private-Branch is iff the task-branch was also identifying
the corresponding change-set. But if you already have an
existing separate mechanism for that (as SVN does, as does
Perforce, and several other tools) then you don't need it
for that purpose, you only need it for the purposes you
state above (because it provides not just an isolated
work area, but an isolated work "stream" in which you can
safely to checkins and make private versions/checkpoints
of incomplete changes without "breaking the build" for the
rest of the team)
--
Brad Appleton <brad@bradapp.net> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Mar 10 23:57:39 2004