Re: "Floating" tags and automating the build process

Scott V. McGuire wrote:

> Right. In our case we want to go for the update/rebase.

Are you sure you want to do "rebasing" instead of "rebranching"?

With a tool that doesnt (yet) support merge-tracking, the common
"rebase" (update) approach may not be the best choice since it gives
repeated merges that the tool may not easily be able to track the TRUE
origin of.

This is one of the main scenarios when rebranching can be preferable to
rebasing. The difference between them is as follows:

- rebasing takes the latest stuff from the trunk and merges it to y our
task-branch.

- rebranching makes a new branch off the trunk and merges your previous
branch to it

So rebasing sort of makes it look like any parallel changes from the
trunk ALSO took place on your branch. Whereas rebranching sys "suppose
that instead of starting my task branch last week, I instead started it
right now - what would the changes on my branch look like then".

The rebranching is, in effect, "faking out" the tool (or someone) by
making a long-transaction look like the equivalent "short transaction"
that began at a later date (so it "pretends" you started your task NOW
instead of last week).

One variation of the rebranching practice is to REUSE the same
task-branch (and equaivelnt way to do it is to delet the old branch and
then rename the "rebranched" branch to the old branch's name). You are
essentially "reparenting" your task branch by making it "spawn" from a
later version than it previously had (e.g., making your branch spawn
from version 7 instead of from version 2 of the parent branch).

-- 
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