[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: branching several times a day (was Re: Sourcesafe user needs primer on branching source control)

From: Brad Appleton <brad_at_bradapp.net>
Date: 2004-03-12 22:44:20 CET

On Fri, Mar 12, 2004 at 04:14:37PM -0500, N. Thomas wrote:
> The only thing I have a question about is this: why would you not delete
> your branch when you are done with it? It makes more sense to start a
> new private branch with a pristine copy -- especially more so for
> Subversion where branching is O(1).

Why did you create your branch? Did you create it so that
you could have a separate stream dedicated to a particular
activity? Or did you create it so you could have a separate
place in which to work on one activity at a time?

If you created a branch-per-task, then the branch is a grouping
mechanism for your resulting change-set for that task. Does SVN
already have a grouping mechanism (independent from branches)
that identifies what my change-set was and all the participating
files and file-changes from the beginning-to-end of my task?

If it has that (I had the impression it does), then do I need
the branch to do that grouping on a per-task basis? Or can I
just use it as a private workstream in which I work on one
task at a time, each task having its own change-set which I
can still identify and diff against as a change-set (rather
than as an entire branch).

> Also, I wouldn't want the history from each feature to be
> muddled with other ones -- something that happens if you
> don't delete the branch.

Why would that happen if you only work on one task at any
given time in your branch and start start a new task until
the previous one is completed? Each change should happen
independently of the other ones - right? And the version of
the codeline that you would want the subsequent change-task
to be based off of is already right there in your branch
and working-copy. The private branch gives you your own
private working-space and versioning-space (the branch) to
checkout and checkin changes in isolation before committing
them. The existing change-set mechanism should give you the
mechanism for identifying and referencing/comparing/diffing
each individual change (unmuddled from the others since they
were non-overlapping), and should be able to do that without
needing the branch.

Or am I misunderstanding/overstating what an SVN change-set
does for you?

> Now if I understand your concept of private branches, I would initially
> branch like this:
>
> /
> /tags
> /trunk
> /branches
> /branches/nthomas
>
> I would add my goodbyeworld feature into /branches/nthomas, and then
> when everything is merged into trunk and synced up, when I want to add
> my hellouniverse feature, I would still work in /branches/nthomas.

Yes.

> But this doesn't make sense since I have now put two unrelated features
> into the same work stream of my SCM.

If you instead created a new branch, you would branch it
off the trunk that already contained the changes for your
previously committed task, yes? So then I'm thinking that in
either case, the initial configuration of the codeline that
is in your workstream at the beginning of that next task is
identical either way.

Is there something stopping me from telling svnlog to give
me the history since my last commit (as opposed to since I
created the branch)? Can I do that without having to create
a tag if SVN tracks the change-set for my task-commit(s)?

[It could be I don't have a good enough understanding of SVN here]

-- 
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 Fri Mar 12 22:46:03 2004

This is an archived mail posted to the Subversion Users mailing list.