Re: Branch management. Merge tracking.

Nick Patavalis <npat@inaccessnetworks.com> wrote:

> I see! So you 're diffing between two distinct points of two branches,
> and not between two "history points" of a single branch. For some
> reason I always thought that merging is only for the latter, but you
> are obviously right. To say it more generally, and please correct me
> if I'm wrong: You are merging into the trunk-wc the differences
> between the trunk---at the last trunk-to-branch merge point---and the
> head of the branch.

Yes, exactly.

> This may sound a bit confusing at first, but It works. The way I
> managed to wrap my mind around it is: If no changes have been made in
> the trunk since r27, then the merge is "mathematically" guaranteed to
> have no conflicts, and the resulting WC is guaranteed to be
> *identical* to the head of the branch (right?). So any conflicts, or
> discrepancies, that may result from "your" merge are due to changes
> made on the trunk, since the last sync-point (i.e. since r27); which
> is something impossible to avoid.

That's correct.

Actually, it's not confusing at all, because it follows exactly the same
model as the relationship between a working copy and a repository.
Merging from trunk to branch is like "svn update"; merging back from
branch to trunk is like "svn commit" (at which point you are committing
the changes between the state of the repository when you last updated,
and the current state of the wc).

-- 
Stefan Haller
Ableton
http://www.ableton.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org