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
http://www.cmcrossroads.com/bradapp/acme/clearcase/RUC2003_SCMA34.zip
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
http://cs.boisestate.edu/~buff/publications/scm9/abstract.html
And slides 21-22 at
http://www.cmcrossroads.com/bradapp/acme/clearcase/RUC2003_SCMA34.zip
(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