On Wed, 01 Nov 2006, Blair Zajac wrote:
> O.Coleman wrote:
> > We're considering moving to subversion from Clearcase, but one of the gripes
> > will certainly be that people miss the nice GUI pictures of merge history. Has
> > anyone made such a GUI tool? It seems like it should be possible, given what
> > Tortoise has done with their Revision Graph.
>
> Yes, that would be nice to have.
Subversion's tools/client-side/svn-graph.pl attempts to produce
GraphViz <http://www.graphviz.org/> descriptors for branch graphs.
It's just a toy at the moment -- to use it, you tweak its source to
point to your repository, then run something like the following
'svn-graph.pl | dotty -'. (Note that this script was busted on
Subversion's trunk until just now, when I fixed it.)
We're eventually going to need a more user friendly tool to produce
graphical representation of branch (or "copy from") history.
Including merge history in this picture seems like a pretty logical
enhancement.
> > Also, from my reading and playing with svnmerge for a bit, it seems you can't
> > do a merge between 2 URL's -- you must have a working copy as a destination. I
> > realize that the limitation is within the spirit of "let the user checkin the
> > changes in the end", but this seems like a downside for our release engineering
> > team to conveniently take changes automatically once they've been approved.
> > Have I missed something?
>
> This isn't a svnmerge.py thing, all merges in Subversion require you to merge
> into a working copy and then commit it.
Subversion itself requires a merge into a WC to avoid the need for
machinery to handle reporting and resolution of committed conflicts.
The WC already records merge conflicts, and the user must resolve
these conflicts before committing.
In addition to requiring a WC, svnmerge.py does not handle the case
where you're explicitly merging the differences between two URLs into
that working copy. Subversion's merge-tracking development branch
doesn't yet have support for this, but has described (at a high level)
the process by which we may be able to account for merge history
during this type of merge operation.
> For automatically take changes, I typically have a working copy just
> for mer[g]ing things into, and a separate set of working copies for
> doing active development.
Yup, this is the expected mode of operation for merging with
Subversion.
- Dan
- application/pgp-signature attachment: stored
Received on Fri Nov 10 04:18:44 2006