Alexis Huxley <ahuxley@gmx.net> writes:
> Perhaps I get more bug reports here, and do the same thing making
> new branches, or maybe I discover my fix for bug001 had a bug, and
> that I need to do some more work on that same branch. Anyway ...
>
> ... Some time later I do a merge, to ensure that the fix for bug001
> makes it into the trunk:
>
> svn merge http://dione.no-ip.org/svn/mumc/branches/release-1.0-bug001 http://dione.no-ip.org/svn/mumc/trunk
>
Not quite. Here's the rule: merges always happen in a *working
copy*. The server cannot perform merges; it can't understand how to
resolve overlapping sections of code, if merges result in any
conflicts. Thus merging is always done by humans, using working
copies.
Thus, you have a working copy that represents, say, the trunk. And
you want to "port" a change (like a bugfix) from the branch to the
trunk. And you know (by reading logs) that in revision X, you
committed the bugfix to the branch.
So your merge command looks like this:
$ cd trunk-wc
$ svn merge -r X-1:X http://.../branches/release-1.0
'svn merge' essentially has the same syntax as 'svn diff'... but the
difference is that instead of *printing* the differences between
revisions X-1 and X of the branch, it actually *applies* the diffs to
your working copy as local changes. Hopefully, you see a bunch of U's
or G's in the output, and not any C's. You resolve any conflicts.
Then you commit the changes, and poof, now the trunk has the bugfix.
(The dirty secret is: this is no different than when you run 'svn
update'. The server is "merging" changes to your working copy every
time you run this command. It just happens to merging in diffs that
have taken place on the same branch as your working copy.)
> And finally, to indicate that that branch is now closed, that all
> appropriate code from the branch has been merged into the trunk,
> I delete it:
>
> svn rm http://dione.no-ip.org/svn/mumc/branches/release-1.0-bug001
>
> How does that sound?
Do you really want to delete the branch? I mean, what if more people
come along and find bugs in 1.0 of your product again? Wouldn't you
want to fix the bug in both the 1.0 branch and the trunk, and release
a new tarball from your branch? Just a matter of policy, here.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 19 18:43:39 2002