Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>Given the choice between Git and Hg, I'd probably go with Git - any disagreement? </p> </blockquote> <p><strong>Warning, I'm a mercurial fanboy.</strong></p> <p>Git is not bad, but it has some quirks you have to know when you use it:</p> <ul> <li>You can push into a non-bare git repo, but this will screw up the working copy there (It moves the branch HEAD to the pushed revision, but does not update the working copy. When you are not aware of this push, the next commit will undo the changes which were pushed into the repo, mixed with the changes you just introduced.). In hg a push to a non-bare repo just add the new history to the repo, and you get a new head on your next commit, which you then can merge with the pushed head.</li> <li>You can't easily switch between a bare and a non-bare repo (you can make a hg repo bare with <code>hg up -r null</code>, and get a working copy with <code>hg up [some-revision]</code> from a bare one).</li> <li>When you check out an older revision by a tag, remote branch name or commit-hash you get a <em><a href="https://stackoverflow.com/questions/3965676/why-did-git-detach-my-head">detached head</a> (I really like the title of that question)</em>. This means commits there are on no branch, and can get removed by the garbage collector. In hg a commit on an old state create a permanently stored anonymous head (You get a warning on the commit).</li> <li>When you come from SVN you have to know that <code>git revert</code> and <code>svn revert</code> do <strong>completely</strong> different things. </li> <li>Git has all features enabled, also the ones which can cause data loss (rebase, reset). In hg these features are there, but must be enabled prior use.</li> <li><code>git tag</code> makes local tags by default, when you want a globally visible tag you need <code>git tag -a</code> or <code>git tag -s</code>. On the opposite <code>hg tag</code> creates a global visible tag, local tags are created with <code>hg tag -l</code>.</li> </ul> <p>Some things many don't like about mercurial:</p> <ul> <li>Branches are stored permanent in the project history, for git-like local branches <a href="https://stackoverflow.com/questions/4319232/mercurial-branching-with-bookmarks/4324493#4324493">bookmarks</a> can be used</li> <li>There are no git-like remote tracking branches (although bookmarks can be shared, and recently there's been work on them to work more like git's branch labels)</li> <li>Creating a tag creates a new commit in the project history (technically git does it the same way, but is <strong>much</strong> better at hiding this commit)</li> <li>You have to enable features that modify history, or are experimental (hg comes pre-packed with many, ... but they are disabled by default). This is why many think that mercurial has less features than git.</li> <li>There is no <code>git rebase -i</code> equivalent packaged with mercurial, you have to get the <a href="https://www.mercurial-scm.org/wiki/HisteditExtension" rel="nofollow noreferrer">third-party histedit extension</a> yourself.</li> </ul> <blockquote> <p>Second, why not Subversion? It seems to be the consensus (not just here) that it's old or otherwise obsolete. Why's that?</p> </blockquote> <p>Svn has no clue what a branch or a tag is, it only know copies. Branches and tags are simulated by having the convention that a svn repo contains a trunk/, branches/ and tags/ folder, but for svn they are only folders.</p> <p>Merging was a pain in svn, because older versions (prior svn 1.5) dit not track the merge history. Since svn1.5 subversion can track merge history, but I don't know if the merging part is better now.</p> <p>Another thing is that in svn every file and folder has it's own version number. In git and hg there is one version for the entire directory structure. This means that in svn you can check out an old revision an one file, and svn will say that there are no local changes in your working copy. When you check out an old revision of one file in git or hg, both tools will say your working copy is dirty, because the tree is not equal to their stored tree. With subversion you can get a Frankenstein version of your sources, without even knowing it.</p> <p>A minor nastiness in svn is that it places a .svn folder in every checked out folder (I heard rumors that they want to change this behavior in 1.7), where the clean reference files for the checked out ones live. This makes tools like <code>grep -r foo</code> not only list the real source files, but also files from these .svn folders.</p> <p>Svn has an advantage when you have big or unrelated projects, since you can check out only subtrees of a repository, while in git and hg you can get only the whole tree at once. Also does svn support locking, which is an interesting feature if you have files which can't easily be merged.</p> <p>Keyword substitution is also supported by svn, but I wouldn't call this a feature.</p>
    singulars
    1. This table or related slice is empty.
    1. POSCM choice for a new user?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USVadim Kotov
    1. USRudi
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POSCM choice for a new user?
      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. VTAcceptedByOriginator
    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