Re: Branching(copying) over merge and commit

I assume that you're talking about what is often referred to as
"rebasing" a branch.

That is, instead of (repeatedly) importing changes from trunk to the
branch, you create a new branch (based on a newer version of trunk)
and move the changes from the old branch to the new one.

In general, I prefer the method that involves moving the least amount
of change around. It's usually the easiest way, and with subversion, I
suspect it's also the most effecient way (both space- and time-wise).

For example, if the trunk is where everybody works (it has a lot of
change), and the branch is a personal branch for feature development
(very little change compared to trunk), I'd use rebasing instead of
merging.

> Is there a lot wasted by doing constant copying.

The copy operation itself is constant-time/constant-space, and almost
free.

The space cost for committing to a copy (i.e. branch) depends on the
back-end. With BDB, a fulltext is stored for the tip of each branch,
so the first commit to a branch is comparatively expensive, even if
the change itself is small. FSFS stores the latest version as a delta
against an earlier version, which is usually a lot more efficient.

- Tor Ringstad -

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 7 15:35:31 2005