Answer the question
In order to leave comments, you need to log in
SVN and urgent changes?
The web project is in SVN, consists of a little over 10 repositories, each repository for each module.
Deployment to production goes in incremental versions: a few commits - a deployment, a few commits - a deployment.
But sometimes there are very urgent tasks (bug fixes) that need to be deployed here and now, while running them through SVN. How can I do this without affecting the main development version?
Use branches? How does it work for you? When fixing a bug, it is necessary that these changes get into the main branch too.
Answer the question
In order to leave comments, you need to log in
Well, I will repeat my answer: habrahabr.ru/qa/7149/#answer_30770
called cherrypicking:
stackoverflow.com/questions/126320/subversion-cherry-picking
I think the GIT logic will suit you just fine. There, for any feature or trifle (hotfix), you make a branch. Thus, the option would suit you: hotfix = make a branch from the release, fix the error, merge into the master (devel) and release. (Everyone calls the working names of the branches differently)
Do you mean that you already have some commits in the trunk that you don’t need to deploy yet, but this urgent last feature needs to be committed?
If you make a branch for each task, and deploy through tags, then you simply will not have such a situation. Roughly speaking, commits (merges from branches) go to the trunk just before the tag is created. Those. at almost any point in time, you have a trunk that matches the latest tag deployed in production. All developers work in branches. Got an urgent task? Please, make a branch and then merge it into vtrank, make a new tag, deploy. Or even like this: there is no time for branches, we fix it right in the trunk, a new tag, deploy.
Look, I recently described my workflow here, which works quite well: habrahabr.ru/qa/7149/#answer_30727
I don't know if this will work in your case with multiple repositories, but the following scheme works quite well for us.
1. For each release, a tag is created (actually a branch) of the form YYYYMMDD
2. Capistrana is finished in such a way that by default it searches for and deploys the latest tag by date
3. If an error was found on live, we correct it in the trunk and merge the changes into the current
tag The last point I threw in a small script that takes the revision numbers for the merge as input and then does everything on its own. Our release cycles are around a week, so in 99% of cases there are no problems with the merge - the trunk code does not have time to change much.
A brunch is made for each deployment.
For an urgent fix:
1) checkout the branch, which is in production
2) fix the bug
3) commit
4) test
[2-4 repeat if necessary]
5) deploy to production.
5) merge into trunk with visual control
6) commit
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question