Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>This is a fairly subjective question, so I wouldn't be opposed to TPTB closing it. However, I'll happily share my opinions on this. Keep in mind that I come from a background working in small/medium (10-50 developers) enterprise contexts, so my opinions are tailored to that environment.</p> <ol> <li><strong>Your developers should understand subversion</strong>. Have them read the <a href="http://svnbook.red-bean.com/" rel="nofollow noreferrer">subversion book</a>, especially the <a href="http://svnbook.red-bean.com/en/1.8/svn.tour.cycle.html" rel="nofollow noreferrer">"basic work cycle"</a> bit. Many of my other suggestions come from the svn book.</li> <li><strong>Commit early and often</strong>. Developers should strive to do work in small chunks that are not breaking or destabilizing. If you aren't checking in your work at least once a day, something is probably wrong.</li> <li><strong>Update extremely often</strong>. You want to pull the latest work the rest of your team has been doing multiple times a day. This also helps ease the pain of merging changes in the event that another developer is working on the same files.</li> <li><strong>Always provide a useful comment</strong>. Developers should write check-in comments that describe the work done in a way that is helpful to the rest of the team. Comments like "fixed build", "more changes", or "x" (true story, I worked with a developer whose comment was always "x") are not useful.</li> </ol> <p>The following are more "admin" guidelines (in your taxonomy), but are still relevant to developers. Also, these are much more subjective, so take with an even larger grain of salt.</p> <ol> <li><strong>Maintain a stable, releasable trunk</strong>. If your developers are following guideline (2) above, you should be able to keep your trunk stable and releasable. Avoid making large, cross-cutting, destabilizing changes -- figure out a way to make those changes in small chunks that are less risky. Maintaining a stable trunk allows you to deploy more frequently, and therefore deliver value to your users faster.</li> <li><strong>Use the <a href="http://svnbook.red-bean.com/en/1.8/svn.branchmerge.commonpatterns.html#svn.branchmerge.commonpatterns.release" rel="nofollow noreferrer">branch-per-release</a> workflow</strong>. Create a new branch for each release in the event that you need to fix bugs. Avoid releasing from trunk or "promoting" from trunk into a static release branch.</li> <li><strong>Avoid feature branches</strong>. Feature branches encourage the kind of destabilizing, cross-cutting changes you want to avoid. Instead, try to make large-scale changes in trunk, but keep them "deactivated" in the production software via configuration switches or the like. You want to strive for an architecture that allows you to implement "big" features without the need to destabilize and isolate the code line. Using Inversion of Control is a big help here.</li> </ol>
    singulars
    1. This table or related slice is empty.
    1. POSVN user guidelines
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USbahrep
    1. USStuart Lange
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POSVN user guidelines
      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. COThat's Stuart. That's a great answer. Very thoughtful. I've up voted for now and will leave the question open for a few more days before accepting.
      singulars
      1. PO
      1. USOliver Moran
    2. COIn addition to *Always provide a useful comment*: If you use an issue tracking system (you do, don't you?), add the relevant ticket ids in the comments as well.
      singulars
      1. PO
      1. USmthomas
 

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