I have a question about feature branches and the way branching works in
subversion. As I understand it from reading the book, "branches" are
really just copies of files (or directories) which share common
ancestry. This suggests that they are symmetric and that it's not
necessarily possible to tell which was the original and which the copy.
Imagine please, the following. We have a trunk. At some point in time,
T=0, we feature branch "A" from the trunk. The developer of "A" is
diligent and consistently merges all changes from the trunk into "A" as
he is working. At a second point in time, T=1, he completes feature
"A", including unit testing on the branch and integration testing with
all extent patches on the trunk.
The traditional approach would now have the developer merge the changes
from "A" into the trunk resulting in T=2 where the trunk and feature
branch "A" were, at least in practice if not lexically, identical,
followed by the removal at T=3 of feature branch "A".
Question: If feature branch "A" and the trunk are identical at time
T=2, including ancestry of all copied files, then why bother? I mean,
wouldn't it be much, much simply at T=1 to simply remove the trunk and
replace it with a copy of feature branch "A"? For that matter, the only
reason for the copy to trunk is to rename it. We could just as easily
drop the old "trunk" and simply declare feature branch "A" to be the new
trunk, couldn't we?
The only difference I can see is that delta(T=2 - T=0) on the trunk =
delta(trunk) + delta(A) whereas the delta(T=2 - T=0) on A = delta(A) +
delta(trunk) but according to the trapezoid rule for vectors, X + Y = Y
+ X even though the history appears different.
I've tried to work this out myself in comparison to other outstanding
branches.
Feature B: branches at T=-1, (ie, before A branches),
merges-by-trunk-replacement at T=0.5, (ie, before A
merges-by-replacement) => Feature A will now merge Feature B changes,
presumably using a diff3 with T=-1 as common ancestor, whereupon
everything proceeds as before.
Feature C: branches at T=-1, (ie, before A branches), merges at T=4,
(ie, after A merges-by-replacement). => Since A is
merging-by-trunk-replacement, C will need to merge A changes from the
new trunk prior to it's own trunk-replacement at T=4. All's still well
with the world.
Feature D: branches at T=0.5, (ie, after A branches, but before A
merges-by-replacement), merges-by-replacement at T=0.75, (ie, before A
merges-by-replacement). => From A's perspective, this is
indistinguishable from any other simple change on the trunk.
Feature E: branches at T=0.5, (ie, after A branches, but before A
merges-by-replacement), merges-by-replacement at T=4, (ie, after A
merges-by-replacement). => This case forces E to merge A changes from
the new trunk prior to it's own trunk-replacement at T=4. Still good.
Feature F: branches at T=4, merges-by-replacement at T=5, (ie, a second
feature branch in series with A, non-overlapping with A) => If a single
merge-by-replacement of the trunk works, then I submit that a second
merge-by-replacement will also work.
Aside from the fact that it requires some bookkeeping, (already required
for merging anyway), and the fact that this approach completely
eliminates the need for one merge, does anyone see any problems with
this approach?
--rich
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 15 16:56:43 2005