You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Nick Patavalis <np...@inaccessnetworks.com> on 2004/12/08 14:58:48 UTC
Branch management. Merge tracking.
I have this svn project
svn://host/repo/proj/{trunk,branches,tags}
And in it the "module" (directory) mod0
svn://host/repo/proj/trunk/mod0
Currently the repository is at revision r0. Since a lot of people are
working on mod0, and since I'm planning to do some heavy restructuring
I decide to create a branch:
svn cp svn://host/repo/proj/trunk/mod0 \
svn://host/repo/proj/branches/my-mod0
So the branch appears at revision r1.
Several days pass by, the restructuring of my-mod0 progresses, and at
the same time others commit minor changes to mod0 at the trunk. From
time to time, I check these trunk-changes and merge them in my branch:
svn merge -r r7:r8 svn://host/repo/proj/trunk/mod0
svn merge -r r12:r13 svn://host/repo/proj/trunk/mod0
(assuming of course a working copy on the branch)
As far as I understand, once I've merged from the trunk to the branch,
I can no longer hope for a way to merge from the branch back to the
trunk; at least not without risking conflicts from the changes merged
earlier from the trunk. So practically it's "one-way" merges only:
Either you merge from branch to trunk, or the other way arround, but
not both. Am I getting something fundamentally wrong?
So I decide not to merge from branch to trunk.
After a couple of weeks latter the restructured my-mod0 is ready,
shiny and clean with the mods of the trunk merged into it. It is time
to move my-mod0 back to trunk and discontinue the branch. How do I do
it? The only way I can think off is something along these lines:
$ cd <trunk-WC>/mod0
$ svn merge -r HEAD:r1 svn://host/repo/proj/trunk/mod0
(bring the trunk back to state of the initial branching)
$ commit
$ svn merge -r r1:HEAD svn://host/repo/proj/branches/my-mod0
$ commit
Can I omit the intermediate "commit"? Is there a better, or
more-canonical way to do it altogether?
Thanks in advance
/npat
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch management. Merge tracking.
Posted by Erik Wasser <er...@iquer.net>.
On Wednesday 08 December 2004 15:58, Nick Patavalis wrote:
> As far as I understand, once I've merged from the trunk to the
> branch, I can no longer hope for a way to merge from the branch back
> to the trunk; at least not without risking conflicts from the changes
> merged earlier from the trunk.
You have to remember the changes you already merged from the branch back
to the main trunk. Or give 'svnmerge' a try.
In my patches directory I got a little textfile for myself like this:
-> 20 Created with revision 20.
-> 21:60 Merged postgresql changes from main trunk
'svn -r 21:60 merge ../../src/. .'
<- 61:62 Merged little changes to the main trunk
'svn -r 61:62 merge ../patches/sawmill/. .'
-> from main trunk to patch
<- from patch to main trunk
With this helpfile I can track the merges from the main trunk to the
patches.
--
So long... Fuzz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch management. Merge tracking.
Posted by Ben Collins-Sussman <su...@collab.net>.
On Dec 8, 2004, at 8:58 AM, Nick Patavalis wrote:
>
> Can I omit the intermediate "commit"?
Not easily. Not without careful repeated merges of ranges that exactly
omit the one commit.
> Is there a better, or
> more-canonical way to do it altogether?
>
This is why we need merge tracking, to avoid repeated merges. :-)
But here's an example of what I'm doing now:
- I'm developing a new feature on a very long-lived branch
- once a week, I merge *all* trunk changes to the branch, that is,
all those changes that happened since the last time I merged.
- when the feature is finished, I'm doing to ask 'svn merge' to
compare
trunk@HEAD with branch@HEAD: the resulting patch will be only
changes made to the branch.
This technique works, as long as you're merging contiguous ranges of
revisions, and not "cherry picking" specific changes.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch management. Merge tracking.
Posted by Nick Patavalis <np...@efault.net>.
On 2004-12-08, Stefan Haller <ha...@ableton.com> wrote:
> Nick Patavalis <np...@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
Re: Branch management. Merge tracking.
Posted by Stefan Haller <ha...@ableton.com>.
Nick Patavalis <np...@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
Re: Branch management. Merge tracking.
Posted by Nick Patavalis <np...@inaccessnetworks.com>.
On 2004-12-08, Stefan Haller <ha...@ableton.com> wrote:
> Nick Patavalis <np...@inaccessnetworks.com> wrote:
>>
>> As far as I understand, once I've merged from the trunk to the branch,
>> I can no longer hope for a way to merge from the branch back to the
>> trunk; at least not without risking conflicts from the changes merged
>> earlier from the trunk. So practically it's "one-way" merges only:
>> Either you merge from branch to trunk, or the other way arround, but
>> not both. Am I getting something fundamentally wrong?
>
> Yes, this is wrong. You can merge both ways without problems provided
> that you have a way to remember which revision ranges you have merged
> from trunk to branch; then you merge everything *except* those ranges
> back from the branch to the trunk.
Yes you 're right this will work. So provided that you don't merge
from trunk to brach very very often (e.g if you do it every week or
so), *and* that you don't *pick* specific trunk mods, then it is
manageable.
>
> At the end, you have a branch that consists of trunk plus changes on
> branch, which means that the final merge back is a single merge like
> this:
>
> cd trunk-wc
> svn merge svn://host/repo/proj/trunk/mod0@r27 \
> svn://host/repo/proj/branches/my-mod0 .
>
>
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.
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.
Thanks for your help
/npat
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Branch management. Merge tracking.
Posted by Stefan Haller <ha...@ableton.com>.
Nick Patavalis <np...@inaccessnetworks.com> wrote:
> Several days pass by, the restructuring of my-mod0 progresses, and at
> the same time others commit minor changes to mod0 at the trunk. From
> time to time, I check these trunk-changes and merge them in my branch:
>
> svn merge -r r7:r8 svn://host/repo/proj/trunk/mod0
> svn merge -r r12:r13 svn://host/repo/proj/trunk/mod0
>
> (assuming of course a working copy on the branch)
>
> As far as I understand, once I've merged from the trunk to the branch,
> I can no longer hope for a way to merge from the branch back to the
> trunk; at least not without risking conflicts from the changes merged
> earlier from the trunk. So practically it's "one-way" merges only:
> Either you merge from branch to trunk, or the other way arround, but
> not both. Am I getting something fundamentally wrong?
Yes, this is wrong. You can merge both ways without problems provided
that you have a way to remember which revision ranges you have merged
from trunk to branch; then you merge everything *except* those ranges
back from the branch to the trunk. In your example:
cd trunk-wc
svn merge -r r1:r7 svn://host/repo/proj/branches/my-mod0
svn merge -r r8:r12 svn://host/repo/proj/branches/my-mod0
svn merge -r r13:HEAD svn://host/repo/proj/branches/my-mod0
However, this is inconvenient and error-prone. In my experience, it is
much easier to keep the range of revisions that you merge from trunk to
branch contiguous, like this:
cd branch-wc
svn merge -r r1:r8 svn://host/repo/proj/trunk/mod0
# a week later:
svn merge -r r8:r13 svn://host/repo/proj/trunk/mod0
# yet another week later:
svn merge -r r13:r27 svn://host/repo/proj/trunk/mod0
At the end, you have a branch that consists of trunk plus changes on
branch, which means that the final merge back is a single merge like
this:
cd trunk-wc
svn merge svn://host/repo/proj/trunk/mod0@r27 \
svn://host/repo/proj/branches/my-mod0 .
--
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