Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Disclosure: This is a <a href="https://stackoverflow.com/questions/2383826/git-based-source-control-in-the-enterprise-suggested-tools-and-practices/2409392#2409392">cross post</a> from another thread that was focused around git, but I ended up recommending mercurial anyway. It deals with DVCS in an enterprise context in general, so I hope cross posting it is fine. I have modified it a little to better fit this question:</p> <hr> <p>Against the common opinion, I think that using a DVCS is an ideal choice in an enterprise setting because it enables very flexible workflows. I will talk about using a DVCS vs. CVCS first, best-practices and then about git in particular.</p> <p><strong>DVCS vs. CVCS in an enterprise context:</strong></p> <p>I wont talk about the general pros/cons here, but rather focus on your context. It is the common conception, that using a DVCS requires a more disciplined team than using a centralized system. This is because a centralized system provides you with an easy way to <em>enforce</em> your workflow, using a decentralized system requires <em>more communication</em> and discipline to stick to the established of conventions. While this may seem like it induces overhead, I see benefit in the increased communication necessary to make it a good process. Your team will need to communicate about code, about changes and about project status in general.</p> <p>Another dimension in the context of discipline is encouraging branching and experiments. Here's a quote from Martin Fowlers recent bliki entry <a href="http://martinfowler.com/bliki/VersionControlTools.html" rel="nofollow noreferrer">on Version Control Tools</a>, he has found a very concise description for this phenomenon.</p> <blockquote> <p>DVCS encourages quick branching for experimentation. You can do branches in Subversion, but the fact that they are visible to all discourages people from opening up a branch for experimental work. Similarly a DVCS encourages check-pointing of work: committing incomplete changes, that may not even compile or pass tests, to your local repository. Again you could do this on a developer branch in Subversion, but the fact that such branches are in the shared space makes people less likely to do so.</p> </blockquote> <p>DVCS enable flexible workflows because they provide changeset tracking via globally unique identifiers in a directed acyclic graph (DAG) instead of simple textual diffs. This allows them to transparently track the origin and history of a changeset, which can be quite important.</p> <p><strong>Workflows:</strong></p> <p>Larry Osterman (a Microsoft dev working on the Windows team) has a <a href="http://blogs.msdn.com/larryosterman/archive/2005/02/01/364840.aspx" rel="nofollow noreferrer">great blog post</a> about the workflow they employ at the Windows team. Most notably they have:</p> <ul> <li>A clean, high quality code only trunk (master repo)</li> <li>All development happens on feature branches</li> <li>Feature teams have team repos</li> <li>They do regularily merge the latest trunk changes into their feature branch (<strong>Forward Integrate</strong>)</li> <li>Complete features must pass several quality gates e.g. review, test coverage, Q&amp;A (repos on their own)</li> <li>If a feature is completed and has acceptable quality it is merged into the trunk (<strong>Reverse Integrate</strong>)</li> </ul> <p>As you can see, having each of these repositories live on their own you can decouple different teams advancing at different paces. Also the possibility to implement a flexible quality gate system distinguishes DVCS from a CVCS. You can solve your permission issues at this level too. Only a handful of people should be allowed access to the master repo. For each level of the hierachy, have a seperate repo with the corresponding access policies. Indeed, this approach can be very flexible on the team level. You should leave it up to each team to decide wether they want to share their team repo among themselves or if they want a more hierachical approach where only the team lead may commit to the team repo. </p> <p><img src="https://i.stack.imgur.com/Hz5ZI.png" alt="Hierachical Repositories"></p> <p>(The picture is stolen from Joel Spolsky's <a href="http://hginit.com/" rel="nofollow noreferrer">hginit.com</a>.)</p> <p>One thing remains to be said at this point, even though DVCS provides great merging capabilities, this is <em>never</em> a replacement for using Continous Integration. Even at that point you have a great deal of flexibility: CI for the trunk repo, CI for team repos, Q&amp;A repos etc. </p> <p><strong>Mercurial in an enterprise context:</strong></p> <p>I don't want to start a git vs. hg flamewar here, you are already on the right track by considering switching to DVCS. Here are a couple of reasons to use Mercurial instead of git:</p> <ul> <li>All plattforms that run python are supported</li> <li>Great GUI tools on all major plattforms (win/linux/OS X), first class merge/vdiff tool integration </li> <li>Very consistent interface, easy transition for svn users</li> <li>Can do most of the things git can do too, but provides a cleaner abstraction. Dangerous operations are are always explicit. Advanced features are provided via extensions that must explicitly be enabled.</li> <li><a href="https://www.mercurial-scm.org/wiki/Support" rel="nofollow noreferrer">Commercial support is available</a> from selenic.</li> </ul> <p>In short, when using DVCS in an enterprise I think it's important to choose a tool that introduces the least friction. For the transition to be successful it's especially important to consider the varying skill between developers (in regards to VCS).</p> <p>There are a couple of resources I'd like to point you to in the end. Joel Spolsky has recently written <a href="http://www.joelonsoftware.com/items/2010/03/17.html" rel="nofollow noreferrer">an article</a> defeating a lot of arguments brought up against DVCS. It must be mentioned others have discovered these contra-arguments long before. Another good resource is Eric Sinks blog, where he wrote an article about <a href="http://www.ericsink.com/articles/vcs_trends.html" rel="nofollow noreferrer">Obstacles to an enterprise DVCS</a>.</p>
    singulars
    1. This table or related slice is empty.
    1. POUsing Mercurial in a Large Organization
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USVadim Kotov
    1. USJohannes Rudolph
    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
    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