Source control issue with deploying versions

we have this discussion about how to deploy to production revisions that are UAT closed without revisions with UAT not-closed status.

We are using SVN and we figured out that we are not able to just take revisions without prior-revisions on the same file made.

Let me explain it on this example: we have 3 revisions made on same file:开发者_StackOverflow社区

r1: UAT closed (ready to deploy) r2: UAT not-closed (not ready) r3: UAT closed (ready to deploy)

now I want to deploy only my changes for which the UAT is closed (e.g. r1 and r3). In SVN this is not possible because r3 contains also r2 changes..

How do you made this to work? Maybe branching? Or just take r1 and wait until r2 is UAT closed?

thanks

Based on what you're saying, I'd suggest branching for each UAT issue, then merging them back to the Trunk when the UAT is closed.

That way you'd have:

Main Branch
 - Branch R1
 - Branch R2
 - Branch R3

Branches 1, 2 and 3 are all commenced at the same time, but R1 and R3 are UAT Closed before R2 is, and a decision is made to go live with what you have.

So you can merge R1 and R3 into Main, but leave R2 where it is.

If you were to go with this process though, I'd also suggest:

Main Branch
- Staging Branch
- - Branch R1
- - Branch R2
- - Branch R3

You can then merge your feature branches into the staging branch, and perform extra integration testing there before merging into live. This can help resolve any conflict happy issue that may pop up when two feature branches are merged together.

Another thing to bear in mind with branching across multiple developers and multiple releases is to find some way to track what changes are on which branch, and what branch has been merged to where. This will be entirely dictated by your working environment and practices though.

I almost always recommend branching for each release. When this is done is usually up to the individual site, but it is usually before the release goes out for UAT testing. This allows you to remove changes that are not ready for the final release.

So, create a release branch and you can put all of your UAT changes there. You could branch from R1, and then merge in the changes in R3, or branch from R3 and backout the change R2 using svn merge (See Undoing Changes in the Subversion on line manual).

Now, you can add and subtract changes that are for the release without interfering with the current project. If R2 does happen to get approved for the release at a later date, it can be merged back into the release branch.

I would not recommend that you create a separate branch for each UAT incident. What you end up with is lots of branches and lots of merging. You end up testing each change individually and approving them, then later find out that they interfere with each other.