Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>It all depends of the <strong><em>sequential nature of your release management</em></strong></p> <p>First, is everything in your trunk <em>really for the next release</em>? You might find out that some of the currently developed functions are:</p> <ul> <li>too complicated and still need to be refined</li> <li>not ready in time</li> <li>interesting but not for this next release</li> </ul> <p>In this case, trunk should contain any current development efforts, but a release branch defined early before the next release can serve as <strong><em>consolidation branch</em></strong> in which only the appropriate code (validated for the next release) is merged, then fixed during the homologation phase, and finally freezed as it goes into production.</p> <p>When it comes to production code, you also need to manage your <em>patch branches</em>, while keeping in mind that:</p> <ul> <li>the first set of patches might actually begin before to first release into production (meaning you know you will go into production with some bugs you can not fix in time, but you can initiate work for those bugs in a separate branch)</li> <li>the other patch branches will have the luxury to start from a well-defined production label</li> </ul> <p>When it comes to dev branch, you can have one trunk, unless you have other development efforts you need to make <em>in parallel</em> like:</p> <ul> <li>massive refactoring</li> <li>testing of a new technical library which might change the way you calls things in other classes</li> <li>beginning of a new release cycle where important architectural changes need to be incorporated.</li> </ul> <p>Now, if your development-release cycle is very sequential, you can just go as the other answers suggest: one trunk and several release branches. That works for small projects where all the development is sure to go into the next release, and can just be freezed and serve as a starting point for release branch, where patches can take place. That is the nominal process, but as soon as you have a more complex project... it is not enough anymore.</p> <hr> <p>To answer Ville M.'s comment:</p> <ul> <li>keep in mind that dev branch doe not mean 'one branch per developer' (which would trigger 'merge madness', in that each developer would have to merge the work of other to see/get their work), but one dev branch per development effort.</li> <li>When those efforts need to be merged back into trunk (or any other "main" or release branch you define), this is the work of the developer, <em>not</em> - I repeat, NOT - the SC Manager (who would not know how to solve any conflicting merge). The project leader may supervise the merge, meaning make sure it starts/finish on time.</li> <li>whoever you choose for actually doing the merge, the most important is: <ul> <li>to have unit tests and/or assembly environment in which you can deploy/test the result of the merge.</li> <li>to have defined a tag <strong><em>before</em></strong> the beginning of the merge in order to be able to get back to previous state if said merge proves itself too complex or rather long to resolve.</li> </ul></li> </ul>
    singulars
    1. This table or related slice is empty.
    1. POHow do you maintain development code and production code?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USArslan Ali
    1. USVonC
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POHow do you maintain development code and production code?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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