StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>I think the DAG of changesets, as mentioned by others, makes a big difference. DVCS:es require split history (and merges) at a fundamental level, whereas I suppose CVCS:es (which are older) where built from day 1 to track revisions and files first, with merge support being added as an afterthought.</p> <p>So:</p> <ul> <li>Merging is easy to do and track in when tags/branches are tracked separately from the directory tree of sources, so the entire repo can be merged in one go.</li> <li>Since DVCS:es have local repos, these are easy to create, so it's turns out it's easy to keep different modules in different repos instead of tracking them all inside a big repo. (so repo-wide merges don't cause the same disruptions as they would be in svn/cvs where one repo often contains many unrelated modules which need to have separate merge histories.)</li> <li>CVS/SVN allows different files in the working directory to come from different revisions, while DVCS:es usually have one revision for the entire WC, always (i.e. even if a file is be reverted to an earlier version, it will show as modified in status as it is different from the file in the checked out revision. SVN/CVS does not show this always.)</li> </ul> <p>Mixing these concepts (as Subversion does) is, I belive, a big mistake. For instance, has branches/tags inside the source tree, so there you have to track which revisions of files have been merged to other files. This is clearly more complex than just tracking which revisions have been merged.</p> <p>So, summarizing:</p> <ul> <li>DVCS:es need easy merges, have have their feature set based on that. Design decision where made so that these merges are easy to do and track (via DAG), and other features (branches/tags/submodules) are implemented to suit that, not the other way around.</li> <li>CVCS:es had some features from the start (such as modules) that made some things easy, but make repo-wide merges very tricky to implement.</li> </ul> <p>At least this is what I feel from my experience with cvs, svn, git and hg. (There probably are other CVCS:es which has got this thing right too.)</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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