> > So what is the proper way to continuously perform the workflow we're
> > trying to do - that is pull changes from origin path into branch, push
> > changes to origin branch from branch, and repeat.
> >
> > Using bidirectional merge (without reintegrate) seems create severe
> > merge conflicts.
>
>
> You can keep the feature branch alive by doing a record only merge on the
> trunk of the revision which your integrate merge was committed as.
Sorry, this should say:
You can keep the feature branch alive by doing a record only merge on the branch from trunk of the revision which your integrate merge was committed as.
BOb
>
>
>
> BOb
>
>
>
> >
> > On Feb 22, 2013, at 7:22 PM, Matthew Pounsett <matt_at_conundrum.com>
> > wrote:
> >
> > >
> > > On 2013/02/22, at 14:15, James Hanley wrote:
> > >
> > >> We are seeing merge tree conflicts where I believe svn is not
> > >> working as expected. I'm not entirely sure if this is due to a
> > >> lack of understanding for proper use on our part, but it was my
> > >> understanding that reintegrate was to be used when pulling changes
> > >> from a branch and pushing them into the copied from branch.
> > >
> > > I asked about this a couple of weeks ago[1] as well. The
> > > explanation I got[2]
> > was that once you've done a --reintegrate, the source of that merge is
> > a dead branch, and cannot be used again. You can demonstrate this
> > much simpler this
> > way:
> > >
> > > cd branches
> > > svn cp ^/trunk ./mybranch
> > > cd mybranch
> > > mkdir foo
> > > svn add foo
> > > svn commit -m "added foo to mybranch"
> > > cd ../../trunk
> > > svn merge --reintegrate ^/branches/mybranch cd ../branches/mybranch
> > > svn merge ^/trunk
> > >
> > > As soon as the --reintegrate is done, ^/branches/mybranch is dead.
> > >
> > >
> > > [1]
> > > <http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mb
> > > ox /%3C01A9EBD6-CE2D-4565-833D-
> 2252CE2E5B71%40conundrum.com%3E>
> > > [2]
> > > <http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mb
> > > ox /%3C20130207150922.GC28403%40ted.stsp.name%3E>
Received on 2013-02-26 23:22:14 CET