qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rupert Smith" <rupertlssm...@googlemail.com>
Subject Re: Merge tools.
Date Thu, 08 Mar 2007 09:20:54 GMT
I should say that svnmerge will be most usefull where M2 has no local
edits, but where bug fixes are applied on trunk and merged accross to
it. As trunk diverges away towards 0.9 it will graudally become less
and less feasible, but hopefully we'll be done by then.

On 3/8/07, Rupert Smith <rupertlssmith@googlemail.com> wrote:
> Some good advice I found on a svnmerge wiki page:
>
> "A well-maintained release branch always has a small avail list of
> revisions which are still to be reviewed and/or discussed for backport
> into the branch."
>
> In other words, if you let your list of avail merges get too long,
> svnmerge won't really help you sort the mess out. The same discipline
> as is required for manual merging is still needed. I assumed svnmerge
> would take care of everything nicely for me, but on the
> perftesting-persistent branch, when I came to merge in some changes
> selected from the paragraph long list of avail revisions, all I got
> was conflicts. Use it by all means, but run it often.
>
> Also, svnmerge will be of limited use to us on M2/trunk as trunk will
> be diverging towards 0.9 and M2 towards its bug fixes. svnmerge only
> really works when there are no local edits.
>
> On 3/8/07, Martin Ritchie <ritchiem@apache.org> wrote:
> > I have been using this on the perftesting_persistent branch and it
> > greatly simplifies merging. If you are wanting to use for the M2
> > branch merging the different languages I would recommend doing the
> > init at the language level. This would allow you to merge each
> > individual language as required but retaining the power of svnmerge
> > telling you what revisions are available for merging.
> >
> > On 07/03/07, Kevin Smith <ksmith@redhat.com> wrote:
> > > Alan Conway wrote:
> > > > Kevin Smith wrote:
> > > >> Alan Conway wrote:
> > > >>> I propose we use http://www.orcaware.com/svn/wiki/Svnmerge.py
to
> > > >>> track merges for us. It will make merging much less error prone.
I'm
> > > >>> going to try it out on the 0-9 branch to backmerge and merge python
> > > >>> and spec prior to merging them to trunk. Its endorsed by the svn
team
> > > >>> and included in the svn distribution. It can be used in conjunction
> > > >>> with manual merges but life will be simpler if we always use it
for
> > > >>> all merges.
> > > >>>
> > > >>> Cheers,
> > > >>> Alan.
> > > >>>
> > > >> I agree. We use this script _a lot_ at my day job and it makes merging
> > > >> much easier.
> > > >>
> > > >> --Kevin
> > > > Kevin, can you give me some tips about selectively merging directories?
> > > > I did svnmerge.py init in the root of the 0.9 branch, and I can
> > > > svnmerge.py avail to seem the available merges but I don't see a way to
> > > > restrict it to certain subdirectories. I could
> > > > a) Merge the whole branch in my working copy and revert all the stuff
I
> > > > dont' want to merge or.
> > > > b) Go thru the (long!) list of diffs to identify the ones that affect
> > > > the directories I'm interested in
> > > > Is there an easier way?
> > > >
> > > > Cheers,
> > > > Alan.
> > > >
> > > >
> > >
> > > Hmmm. We use the tool to operate on whole branches, so we haven't run into
this
> > > particular use case. I'm pretty sure svnmerge isn't really suited for this,
> > > though :(
> > >
> > > When I do need to selectively merge stuff (happens quite a bit) I use "svn
> > > merge". This method does require that you know the repo version number you
want
> > > to merge. Assuming I want to merge the change in version 123456, the command
> > > looks like this:
> > >
> > > svn merge -r 123455:123456 /trunk/path/to/some/file_or_dir
> > > (merges into the current working directory)
> > >
> > > or
> > >
> > > svn merge -r 123455:123456 /trunk/path/to/some/file_or_dir /branch/other/path
> > > (merges to specific path)
> > >
> > > hth,
> > > Kevin
> > >
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Martin Ritchie
> >
>

Mime
View raw message