> -----Original Message----- > From: Watson, Paul [mailto:pwat...@phs.org] > Sent: 21 March 2016 15:45 > > We are using Subversion 1.7. I am trying to document a hotfix methodology. > The project has the traditional "TTB" directories. > > app/trunk > app/tags/1.0 > app/tags/1.1 > app/branches > > 1.1 is deployed and running in production when a problem occurs. We cannot > tag the current trunk and deploy since developers have been making changes > and adding features since 1.1 was tagged. > > It seems that making a branch from app/tags/1.1 to app/branches/1.1_hotfix is > the right thing to do. Then, 1.1_hotfix can be checked out, changed, tested, > checked back in, and deployed to production. Ok so far?
Alternatively you could "recreate" the missing trunk->branch->tag branch by copying the tag's original source revision of trunk to a new branch and working on that. Then you will also be able to merge you changes back to trunk. ~ Mark C > How can the 1.1_hotfix changes be merged back into the trunk? Using 'svn up' > does not appear to recognize trunk changes. I assume this is because > 1.1_hotfix came from tags/1.1 and not trunk. Is that correct? > > I am expecting the same problems from 'svn merge' and 'svn merge -- > reintegrate'. I do -not- want to change tags/1.1 which should remain golden. > From the red book: > > " The second form is called a “reintegrate merge” and is used to bring > changes from a feature branch (SOURCE) back into the feature > branch's immediate ancestor branch (TARGET_WCPATH)." > > I am seeking to get the changes back into mainline trunk development. Is this > possible? Should I not want to do this?
