On 2004-12-08, Stefan Haller <haller@ableton.com> wrote:
> Nick Patavalis <npat@inaccessnetworks.com> wrote:
>
> 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).
>
Again you 're right. Your comments really helped me sort some things
out in my mind. The way I conceptualize it now is that there are two
"types" or "uses" of branches.
The first type, the one I had in mind originally, was like a branch
you create before, say, shipping a release to a customer: You fork you
trunk to create a stable branch and this becomes a permanent sibling
of you development mainline. Occasionally you cherry-pick fixes from
the trunk and move them to the branch. Sometimes you even do it the
other-way around: You cherry-pick a feature from the branch and merge
it to the branch. But the two paths never actually *merge* or *track
each-other*. In this case all merges you do are of this kind:
branch -r X:Y ---> trunk
and
trunk -r K:L ---> branch
I had never thought of the possibility of a "type-II" branch; one that
conceptually *tracks* the trunk. In this case it is, as you correctly
pointed out, preferable to think of the branch / trunk relationship in
terms of working-copy (the branch) and repository (the trunk), and the
merges between them in terms of "commits" (from branch to trunk) and
"updates" (from trunk to branch). In this scenario the merges you do
are of these kinds:
trunk -r X:Y ---> branch (the update)
and
trunk@Y branch@HEAD ---> trunk (the commit)
In trivial cases, of-course, the merges between type-I branches and
the merges between type-II branches are the same. But nevertheless,
you have to approach the two branch-application scenaria from
different viewpoints otherwise you'll get confused.
Which makes we wonder about two things:
First: Is there some literature (of any kind) discussing "fundamental"
VC practices (for lack of a better name), or maybe even attempting to
formalize on them?
And second: Wouldn't it be better if you were actually able to use
concepts like these at a higher-level, so that---using these imaginary
tools---every allowed merge operation would be a *meaningful* one,
depending of the "type" (purpose) of branch you have selected to
create? (I'm desperately in need of some better terminology, but I
hope you understand the point).
Anyway, thanks again for you help.
Regards
/npat
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Dec 9 00:12:36 2004