Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I think your best bet is reviewing Mercurial's suggested <a href="http://mercurial.selenic.com/wiki/Workflows" rel="nofollow">workflows</a>. I can tell you from my own experience with a structured release cycle that had code (features, enhancements, and bug fixes) going to a QA environment for verification and prepping releases, then branching from those release tags for emergency patches, Mercurial fits nicely.</p> <p>For my steps below, "trunk" is just what others might call mainline. There isn't any term "trunk" in Mercurial. You just have the repository you are working from, which is either just your local repository or a clone of another repository (still local).</p> <ol> <li>trunk is where everyone generally works.</li> <li>When a particular change is completed, it is pushed to a central server (still trunk and a central server is optional, just makes the workflow easier with continuous integration).</li> <li>From the central server repository, a build is done and pushed to the QA server.</li> <li>QA tests the functionality and should also generally test limited interaction outside the known change.</li> <li>If change passes QA testing, a release manager may choose to tag that changeset as the version number to be released (<code>hg tag "name of tag"</code>).</li> <li>Once code is tagged and ready for a release, another build can be done to push to a user acceptance test environment (UAT), which mimics production configuration.</li> <li>If UAT passes, a final build can be done to push into production. Note that you can save some build steps by using separate "build" repositories that hold only pre-built copies of your software. That way, only a single build needs to be done if QA and UAT testing passes before pushing to production.</li> <li>If a defect is found in the production release, a branch can be created from the tagged revision that was released (say 1.0.0) using <code>hg update "tag name"</code> then <code>hg branch "name of branch"</code> (which should probably match the tag name).</li> <li>While "on" the branch revision, fix the bug, commit, merge it to "trunk".</li> <li>Do a build from the latest revision "on" the branch and push that to QA.</li> <li>If testing is successful, that build can be moved to UAT and production as necessary and you can feel confident that you are only releasing that single bug fix.</li> </ol> <p>All the while, new functionality, features, and non-critical bug fixes can be done in "trunk", continuing with the "next" version of the code to be released on a schedule.</p>
    singulars
    1. This table or related slice is empty.
    1. POmercurial workflow with multiple non-live environments
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USSumo
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. 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