If you mean literaly using the --reintegrate feature then you can cause
problems. The svn book says NOT to do this. I can't recall the reasons.
"In Subversion 1.5, once a --reintegrate merge is done from branch to
trunk, the branch is no longer usable for further work. It's not able to
correctly absorb new trunk changes, nor can it be properly reintegrated
to trunk again. For this reason, if you want to keep working on your
feature branch, we recommend destroying it and then re-creating it from
the trunk:"
BOb
> -----Original Message-----
> From: Brian Erickson [mailto:erickson_at_bauercontrols.com]
> Sent: Friday, February 20, 2009 2:33 PM
> To: Mark Phippard; users_at_subversion.tigris.org
> Subject: RE: Fwd: svn1.5 seems to fail simple merge-tracking scenario
>
> In my case, we have 4 people working on a feature branch. At various
> checkpoints, defined by the systems manager, we re-integrate back to
the
> trunk.
>
> If we remove and re-create the branch, what happens to our working
> copies?
>
> Thanks,
> Brian
>
> > -----Original Message-----
> > From: Mark Phippard [mailto:markphip_at_gmail.com]
> > Sent: Friday, February 20, 2009 11:24 AM
> > To: Nathan Nobbe; users_at_subversion.tigris.org
> > Subject: Re: Fwd: svn1.5 seems to fail simple merge-tracking
scenario
> >
> > On Fri, Feb 20, 2009 at 11:20 AM, Stefan Sperling
> > <stsp_at_elego.de> wrote:
> > > On Fri, Feb 20, 2009 at 08:57:28AM -0700, Nathan Nobbe wrote:
> > >>
> > >> hi,
> > >>
> > >> we are migrating to svn1.5 at the office. ive been
> > running some tests
> > >> using the svn1.5.5 merge tracking and ive run a simple
> > bidirectional
> > >> merge test, and i dont see it leveraging the merge
> > tracking. let me
> > >> illustrate the flow, and open up the floor to folks who
> > can clarify
> > >> things for me.
> > >> imagine there is a file in a branch,
> > $branches/test/a.c, then a branch
> > >> is created from there,
> > >> svn cp $branches/test $branches/test-b
> > >> ok, now, we checkout both branchs, and make a change to a.c,
in
> > >> test-b, and commit it.
> > >> cd test-b
> > >> vi a.c # add a line
> > >> svn commit a.c
> > >> then we merge back to upstream,
> > >> cd ..
> > >> svn up test
> > >> svn merge --reintegrate $branches/test-b test
> > >> svn commit -m 'merge --reintegrate test-b' test
> > >> now the change from test-b is in test. so now, we go
> > into test-b,
> > >> and
> > >
> > > Don't go on using $branches/test-b after you have reintegrated it.
> > > You want to svn rm $branches/test-b at this point.
> > > If you need it again, re-branch.
> > >
> > > See http://blogs.open.collab.net/svn/2008/07/subversion-merg.html
> >
> > The alternative is that you can use the svn merge
> > --record-only option to record the merge on test-b so that
> > subsequent merges do not attempt to merge back that revision.
> >
> > Personally, I think removing the branch and recreating
> > when/if there is more to do is cleaner.
> >
> > --
> > Thanks
> >
> > Mark Phippard
> > http://markphip.blogspot.com/
> >
> > ------------------------------------------------------
> > http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&
> > dsMessageId=1199151
> >
> > To unsubscribe from this discussion, e-mail:
> > [users-unsubscribe_at_subversion.tigris.org].
> >
>
> ------------------------------------------------------
>
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageI
d=
> 1200148
>
> To unsubscribe from this discussion, e-mail: [users-
> unsubscribe_at_subversion.tigris.org].
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1200171
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-20 20:39:16 CET