Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>In Subversion (and CVS), the repository is first and foremost. In git and mercurial there is not really the concept of a repository in the same way; here changes are the central theme.</p> </blockquote> <p>+1</p> <p>The hassle in CVS/SVN comes from the fact that these systems do <strong>not</strong> remember the parenthood of changes. In Git and Mercurial, not only can a commit have multiple children, it can also have multiple parents!</p> <p>That can easily observed using one of the graphical tools, <code>gitk</code> or <code>hg view</code>. In the following example, branch #2 was forked from #1 at commit A, and has since been merged once (at M, merged with commit B):</p> <pre><code>o---A---o---B---o---C (branch #1) \ \ o---o---M---X---? (branch #2) </code></pre> <p>Note how A and B have two children, whereas M has two <strong>parents</strong>. These relationships are <em>recorded</em> in the repository. Let's say the maintainer of branch #2 now wants to merge the latest changes from branch #1, they can issue a command such as:</p> <pre><code>$ git merge branch-1 </code></pre> <p>and the tool will automatically know that the <em>base</em> is B--because it was recorded in commit M, an ancestor of the tip of #2--and that it has to merge whatever happened between B and C. CVS does not record this information, nor did SVN prior to version 1.5. In these systems, the graph would look like:</p> <pre><code>o---A---o---B---o---C (branch #1) \ o---o---M---X---? (branch #2) </code></pre> <p>where M is just a gigantic "squashed" commit of everything that happened between A and B, applied on top of M. Note that after the deed is done, there is <em>no trace left</em> (except potentially in human-readable comments) of where M did originate from, nor of <em>how many</em> commits were collapsed together--making history much more impenetrable.</p> <p>Worse still, performing a second merge becomes a nightmare: one has to figure out what the merge base was at the time of the first merge (and one <em>has</em> to <em>know</em> that there has been a merge in the first place!), then present that information to the tool so that it does not try to replay A..B on top of M. All of this is difficult enough when working in close collaboration, but is simply impossible in a distributed environment.</p> <p>A (related) problem is that there is no way to answer the question: "does X contain B?" where B is a potentially important bug fix. So, why not just record that information in the commit, since it is <em>known</em> at merge time!</p> <p>P.-S. -- I have no experience with SVN 1.5+ merge recording abilities, but the workflow seems to be much more contrived than in the distributed systems. If that is indeed the case, it's probably because--as mentioned in the above comment--the focus is put on repository organization rather than on the changes themselves.</p>
    singulars
    1. This table or related slice is empty.
    1. POWhy is branching and merging easier in Mercurial than in Subversion?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USDamien Diederen
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POWhy is branching and merging easier in Mercurial than in Subversion?
      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. VTAcceptedByOriginator
    1. COSVN 1.5+ would indeed put an SVN property on the merge commit M listing the merged commits it contains, in other words A-B. So you have the same information.
      singulars
      1. PO
      1. USSimon D
    2. COKind of. Technically, SVN's merge tracking is akin to what Git calls “cherry-picking,” with additional magic to make it easier on the user; it is semantically different from what Git, Hg and Bzr do when merging. I guess it does not make a lot of difference in practice as long as you do not care about the DAG (http://eagain.net/articles/git-for-computer-scientists/).
      singulars
      1. PO
      1. USDamien Diederen
    3. COWoe that there is no +100 button. Thanks.
      singulars
      1. PO
      1. USCharlie Flowers
 

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