Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>That's a big question. I only have ideas how to solve some of the problems:</p> <ol> <li>I don't think this can easily be solved without using branches a lot. Not sure if this can be easily solved by using GIT either. Feature branches go a long way in solving this problem, but in general you should probably try to concentrate on features for the next release only.</li> <li><code>trunk</code> - I consider it the <code>master</code> branch.</li> <li>I'd say the <code>development</code> branch is the code for the next release</li> <li>Seems difficult without using a lot of branches, no idea how to properly solve this.</li> <li>You could use branches or note the revision number being in TEST and ACC. PROD should be put into a tag I guess.</li> <li>I'd say using automated regression tests and continuous integration. Also using peer reviews can help here, at best you use some sort of tool to mark a file as reviewed. That way you can ensure that you only merge files that have been reviewed. It could also be interesting to tie your commit messages to your bugtracker, to automatically figure out which files have been touched in relation to which issues, and then make sure all issues are actually closed for the files you want to merge. This is a non trivial task, especially if you are thinking about merging only parts of branches. Thereby, sort of, doing a feature merge.</li> <li>Use a tag for the release. You can check it out just like a branch and add patches if necessary</li> <li>List all svn commits for the entire repository on one page (e.g. trac/redmine/jira overview)</li> <li>Use a local copy I'm afraid/or a branch again. Or make the R&amp;D use git svn locally for research.</li> </ol> <p>Some of these problems can, at least partly, be solved by using <code>git svn</code>. By using it you can for example to experiments locally using gits branch features, without storing those in the global repository. Of course this is not interesting if you are exploring a new feature with many members on a team, unless they are all comfortable with using git and pulling from each other over the network. By using <code>git svn</code> you can also use <code>git cherrypick</code> to hand pick single commits to apply from one branch to another (e.g. development onto released-x.x-tag).</p> <p>That's all I could come up with for now, hope it helps.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload