Ben Collins-Sussman <sussman@collab.net> writes:
> '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.)
Sorry, let me clarify. It goes back to my old diagram I posted last
week:
'svn update' merges *permanent* changes into your wc
'svn merge' merges *local* changes into your wc (they can be reverted)
'svn diff' merely prints the changes to the screen.
> > 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.
Reading your mail again, I think the point I'm trying to make is that
it's not customary to repeat the cycle of {create a branch, fix a bug
on it, port the change to trunk, delete the branch}.
Often, projects just maintain two independent lines of development.
New work happens on the trunk, and only bugfixes happen on the
released branch. But they both stay open for a long time, trading
bugfixes back and forth in *both* directions. Every once in a while,
a new release is made from the branch.
Of course, that scenario assumes you have customers to support, who
are paying for support on the 1.0.X "released" product. In an
open-source project, "development" and "release" branches aren't as
common... people just ususally all move forward on a single trunk.
(Some notable exceptions, though, are FreeBSD and Debian; both of
those projects have several branches you can choose to install, of
varying levels of stability.)
Another common use of branches *is* to make "temporary" ones -- it's a
technique that we've already used in subversion. If somebody is
working on *big* new change or feature that will surely screw everyone
else up if they commit it in pieces (break the build, etc.), they
create a "private" branch. So cmpilato created a branch for his
filesystem rewrite, and worked on that for a while. kfogel has a
branch where some unfinished bug #662 work is still in progress. When
the major bug or task is completed, kfogel and cmpilato merge their
branch changes back into trunk, and delete the private branches. By
committing small changes each day to their branch, it allows gstein
and others to review the code incrementally, rather than one *massive*
change being committed to trunk out of the blue.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 19 19:03:35 2002