Managing merges

[Alan Conway <ac...@redhat.com>]

Subversion, is of no help at all in tracking what has been merged from
one branch to another so the risk of double-merging is very high.

http://www.dellroad.org/svnmerge/index claims to be a tool to record
merges in svn properties automatically avoid double merges etc. It's
been adopted by tigris and is part of the svn distribution (although not
installed by the fedora RPM package I have.)

Anyone have any experience with this? If its any good it would be worth
adopting for qpid. Anyone know of better solutions to managing merges on
svn? 

Cheers,
Alan.

Re: Managing merges

[Andrew Stitcher <as...@redhat.com>]

On Thu, 2007-01-11 at 14:01 +0100, Jim Meyering wrote:
> Steve Vinoski <vi...@iona.com> wrote:
> ...
> > Such a conversion to git isn't really practical, given that qpid sits
> > within a much larger svn repository consisting of many projects.
> 
> Note that I wasn't proposing the removal of the SVN repository.  It is
> possible (at least theoretically -- not sure the SVN-based git tools are
> as functional/reliable as the CVS ones, e.g., for branches) to commit to
> a git repository and have those changes mirrored automatically to the
> existing svn one.  That's what I do with git+cvs on savannah.
> ...
> A less ambitious move that should still provide better built-in
> merging tools, would be to use SVK.  That has the advantage that
> the underlying repository is SVN-based.  But I haven't been
> following it's development, so don't know how feasible a switch
> would be.

Well as far as I understand this would be quite feasible as the basic
mode of use of SVK is to mirror an existing svn repository anyway. So
essentially you mirror the qpid repository into a branch, then copy this
into a private branch to do your work; then you merge back into the
mirrored branch and that automatically pushes your changes upstream.

Andrew

Re: Managing merges

[Jim Meyering <ji...@meyering.net>]

Steve Vinoski <vi...@iona.com> wrote:
> On Jan 11, 2007, at 6:23 AM, Jim Meyering wrote:
...
>> But I'm getting way ahead of myself.  With inertia and all that, I
>> suspect
>> no one will be pushing to convert the repo to git in the short term.
>> Probably not at all.
>
> Such a conversion to git isn't really practical, given that qpid sits
> within a much larger svn repository consisting of many projects.

Note that I wasn't proposing the removal of the SVN repository.  It is
possible (at least theoretically -- not sure the SVN-based git tools are
as functional/reliable as the CVS ones, e.g., for branches) to commit to
a git repository and have those changes mirrored automatically to the
existing svn one.  That's what I do with git+cvs on savannah.

Here's the web view of the git tree:
  http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=summary
and here's the view (different tool) of the CVS one that
contains all the same deltas:
  http://cvs.sv.gnu.org/viewcvs/coreutils/coreutils/#dirlist

A less ambitious move that should still provide better built-in
merging tools, would be to use SVK.  That has the advantage that
the underlying repository is SVN-based.  But I haven't been
following it's development, so don't know how feasible a switch
would be.

Re: Managing merges

[Steve Vinoski <vi...@iona.com>]

On Jan 11, 2007, at 6:23 AM, Jim Meyering wrote:
> If switching technology altogether is an option (yeah, right, but  
> let's
> be crazily optimistic), consider git, too.  Its merge capabilities are
> very good.  E.g., check out the man pages for these tools: git- 
> rebase and
> git-rerere.  And there are tons of (some say too many) examples in  
> git's
> Documentation directory.  Be sure to look at the very latest (e.g.  
> 1.4.4.4
> or better), since the documentation has been improving steadily.

<snip/>

> In case anyone is interested for qpid, the repo-conversion
> tools work pretty well.  Between git's git-svnimport and tailor
> (http://darcs.net/DarcsWiki/Tailor, a tool to convert nearly any  
> VCS to
> any other), it should be easy to perform the initial svn->git  
> conversion.
> But I'm getting way ahead of myself.  With inertia and all that, I  
> suspect
> no one will be pushing to convert the repo to git in the short term.
> Probably not at all.

Such a conversion to git isn't really practical, given that qpid sits  
within a much larger svn repository consisting of many projects.

--steve

Re: Managing merges

[Jim Meyering <ji...@meyering.net>]

Andrew Stitcher <as...@redhat.com> wrote:
> Looking at the subversion website it appears that svnmerge.py is now
> maintained as part of the subversion distribution so that makes it
> almost "blessed" by subversion. It looks like they are planning to use
> svnmerge as a sort of model for the merge tracking support in future
> versions of svn so it looks like it might be the best future proof
> solution.
>
> Another possibility is to use SVK (http://svk.bestpractical.com/)which
> also supports merge tracking, and uses svn as its underlying storage and
> can also be used to mirror svn repositories. However this would probably
> only work to manage individual branches and these would then be in a
> different repository from the main qpid repo.

If switching technology altogether is an option (yeah, right, but let's
be crazily optimistic), consider git, too.  Its merge capabilities are
very good.  E.g., check out the man pages for these tools: git-rebase and
git-rerere.  And there are tons of (some say too many) examples in git's
Documentation directory.  Be sure to look at the very latest (e.g. 1.4.4.4
or better), since the documentation has been improving steadily.

SVK was the first dVCS (distributed version control system) I ever used.
I tried it almost two years ago, and really liked the ability to work
totally disconnected, cheap private branches, etc. -- this was before
git/mercurial were serious contenders.  svk was young too, but it did work
and had a stable back-end... and there was even usable Emacs vc-mode
support :)

Since then, I've spent a lot of time evaluating both git and hg, because
I wanted to switch upstream coreutils development from CVS to a dVCS .
Once you get a taste of working with a dVCS, using the likes of CVS and
SVN will feel like a taking a big step backwards.  I settled on git[*] and
have never looked back.  I flipped the switch on the upstream coreutils
repository in October.  Now, all changes are committed into the git
repository, and automatically mirrored to the legacy (otherwise-read-only)
CVS repository, so the older infrastructure still works (e.g., cvsweb).

In case anyone is interested for qpid, the repo-conversion
tools work pretty well.  Between git's git-svnimport and tailor
(http://darcs.net/DarcsWiki/Tailor, a tool to convert nearly any VCS to
any other), it should be easy to perform the initial svn->git conversion.
But I'm getting way ahead of myself.  With inertia and all that, I suspect
no one will be pushing to convert the repo to git in the short term.
Probably not at all.

Jim

[*] I've made the git-over-hg case on a couple other forums, if you're
interested let me know and I'll dig up the links.

Re: Managing merges

[Andrew Stitcher <as...@redhat.com>]

Looking at the subversion website it appears that svnmerge.py is now
maintained as part of the subversion distribution so that makes it
almost "blessed" by subversion. It looks like they are planning to use
svnmerge as a sort of model for the merge tracking support in future
versions of svn so it looks like it might be the best future proof
solution.

Another possibility is to use SVK (http://svk.bestpractical.com/)which
also supports merge tracking, and uses svn as its underlying storage and
can also be used to mirror svn repositories. However this would probably
only work to manage individual branches and these would then be in a
different repository from the main qpid repo.

I have tried to use svk to allow me to manage my own qpid development
(as I don't have commiter rights yet) but I ran into some problems
trying to mirror the whole qpid tree - this seems to appear when trying
to mirror version 488160 of the repo. It seems to work fine though with
a small branch (qpid.0-9) created after this repo version.

Andrew

On Wed, 2007-01-10 at 18:08 -0500, Alan Conway wrote:
> Subversion, is of no help at all in tracking what has been merged from
> one branch to another so the risk of double-merging is very high.
> 
> http://www.dellroad.org/svnmerge/index claims to be a tool to record
> merges in svn properties automatically avoid double merges etc. It's
> been adopted by tigris and is part of the svn distribution (although not
> installed by the fedora RPM package I have.)
> 
> Anyone have any experience with this? If its any good it would be worth
> adopting for qpid. Anyone know of better solutions to managing merges on
> svn? 
> 
> Cheers,
> Alan.
>