> Since major refactoring is going on in the trunk, changes are
> backported by hand, not using svn merge. My understanding of
> reintegrate (apparently wrong, but based on some research) is that
> after re-integrate, there should be no diffs.
Well... reintegrate is not going to work if you are manually merging staging changes into trunk. The use case for reintegrate would be that you create a branch to add a feature. Each week you merge from trunk into branch to keep up with any changes made in trunk. Once you are done you would then reintegrate branch into trunk which would bring changes created in branch into your trunk.
So before you reintegrate the trunk into the branch all changes made in trunk really need to be merged into the branch. Under your use case you really should be merging staging into trunk... but apparently that won't work due to your refactoring, I assume you would have a lot of tree conflicts.
> The reason for accepting all changes from trunk is that all changes
> have been backported and the trunk is considered stable. We do not
> want any changes from the old staging branch sticking around. Simply
> going to staging and doing an svn merge will leave me dealing with
> conflicts and potentially diffs since the backport is not always the
> same as the original change.
So, if you basically want staging the be a copy of trunk again, I think your best bet is to just delete staging and re-created it from trunk.
> Perhaps my #2 or #3 options are appropriate under these circumstances.
Another work flow that you could try, which the subversion devs use is to branch for release (similar to your staging). In this case, you don't fix bugs in the branch. You fix them in trunk then merge the fixes you want included in your release into your stagging branch.
Hth,
BOb
>
> On Sep 14, 12:17 pm, Alex <alex.lii..._at_gmail.com> wrote:
> > Here is my branch structure
> > - trunk
> > - branches/staging
> > - branches/production
> >
> > We do you primary development on trunk, and do bug fixes on staging.
> > When trunk is ready and stable, I want to merge all of those to
> > staging. Our deployment system (beanstalkapp.com) always deploys
> from
> > branches/staging.
> >
> > I have three choices:
> > 1) Merge changes from trunk into branches/staging. I have tried in
> > branches/staging:
> >
> > svn merge --reintegratehttp://[url]/trunk ./ --accept theirs-full
> >
> > but this leaves diffs when I go the root and do:
> >
> > diff -r trunk/ branches/staging --exclude=.svn
> >
> > 2) Move branches/staging to branches/staging-[date/version] . Then
> > copy trunk to branches/staging.
> >
> > 3) Copy trunk go branches/staging-[date/version], then update our
> > deployment system to deploy from the new branch.
> >
> > I have been doing (2), but I don't really like it. (1) seems to
> > better keep track of revisions, but I'm willing to accept that might
> > be wrong.
> >
> > Ideally subversion would support some type of "symbolic link". I
> > could have branches/staging-v1.3 and branches/staging could be a
> > symbolic link there. This would allow the deployment system to not
> > need to be updated every time.
> >
> > Any thoughts?
> >
> > Thanks.
> >
> > ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessa..
> .
> >
> > To unsubscribe from this discussion, e-mail: [users-
> unsubscr..._at_subversion.tigris.org].
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessage
> Id=2394755
>
> To unsubscribe from this discussion, e-mail: [users-
> unsubscribe_at_subversion.tigris.org].
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2394770
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-14 22:11:11 CEST