[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

From: Brad Appleton <brad_at_bradapp.net>
Date: 2004-03-19 06:35:42 CET

On Wed, Mar 17, 2004 at 01:46:55AM +0200, Nuutti Kotivuori wrote:
> What is the term usually used to describe a single change (with a log
> message usually) that has been "checked-in" to any branch?

If its "checked-in" to a private-branch or a task-branch and
the corresponding task is not yet finished, the common term
I've heard (which the PrivateVersions pattern uses) is a
"checkpoint", and the process of doing it is often called
"checkpointing" (e.g., I've created a private "checkpoint"
of my changes on my branch of my working-copy, but until I
actually merge my changes to the codeline, I haven't really
"committed" them (to the codeline) because theya rent yet
visible to the rest of the team.

> > Why is it necessary to rebranch the branch (I assume you mean
> > "reparent" the branch to a subsequent version of the trunk - which
> > is almost what a "rebase" or "rebaseline operation does, in
> > theory).
> Almost, but not exactly. "Reparenting" or "rebaselining" usually means
> taking a change-set against an earlier version of mainline (or
> baseline, heh), and adapting it to be against a later version of
> mainline - eg. keeping the changes made on the branch, but just making
> them be based against a later version of trunk.

Okay. so for me, branch reparenting, rebranching, and branch rebaselining
have a subtle but important difference.

* Rebasing (or Rebaselining) is "porting" the latest stuff from
  the codeline (trunk) into my branch. See slides 19-20 at
  I thought that "cvs update" did the same thing?
* What I call "Rebranching" is described in an SCM-9 paper by
  Buffenbarger and Gruell, see
  And slides 21-22 at

(slide 38 discusses some pros-vs-cons of rebasing and rebranching)

* Branch reparenting is described well in Michael Bay's book
  "Software Release Methodology". It's a "trick" that has
  the same effect as "rebranching" but without having to create
  a new/separate branch. I think that in terms of history tho,
  its slightly different from rebasing and rebranching (not
  sure about that)

> And again - smart merging only alleviates the merge conflicts and
> allows you to do things differently, but it does not change the
> logical issue here.

Agreed. I don't usually see it causing any problems tho. But
see the "Whole IS the sum of its parts" section of my earlier
post - in those cases, it can be problematic.

> branches. Both of these issues would probably become clear as water by
> reading the Subversion book. It really isn't that bad of a a read -
> and if you are looking to cut time, reading just Chapter 4 should be
> enough, with first peeking through Chapter 2 Section 3.2 in case
> there's something uncertain as to what revisions in Subversion
> actually mean.

Actually - I have read it, but its been a while (I think two
years) and there have been changes, and I haven't been able to
play with it to keep it fresh in my mind. Your examples were
useful to me. Many thanks!!!

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 19 06:36:18 2004

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