GIT, HG and other DVCS vs VSS, SVN and other SVCS: in the first trees are orthogonal, in the second - mixed!

Seemingly, I missed the fact that no one anywhere is clearly trying to write - and without this I somehow could not understand. I have quite a lot of experience working in VSS and some experience looking out for SVN. And now I look at GIT.

On the page mercurial.selenic.com/wiki/UnderstandingMercurial it is said at the end that if you are thinking of keeping several related projects in one HG repository, as you are used to in systems like SVN, then think again, because HG is not designed for this. This seems to be because it always works with the entire working folder as a whole.

This is a good example of the consequence of what I want to say: among these new-fashioned distributed systems, the concept of a directory tree and files in a working folder is orthogonal to its version tree . This is the second (after having a local repository ) key difference between these systems from previous ones.
')
In SVN and VSS, different versions of the same working folder were suggested to be arranged by neighboring folders in other repository folders, and accordingly the repository folder tree contained not one working folder, but a whole set of them lying in different subfolders in a separate specially fabricated root folder of the repository and a number of its service subfolders such as branch and trunk. This led the system to the need to give the user the opportunity to work with one separate subfolder of the repository, then with another, and copy one into another while preserving history, merge neighboring folders with one another, and so on. And, as a consequence of this skill, these systems made it possible in other subfolders of the same repository to store versions of the working folders of other, related projects. And accordingly, the rights to different folders are different for different people. Who alone can not see who others do not edit.

GIT and HG separated the concepts of the version tree and the folder tree, and therefore did not initially need to support work with subfolders, and always work in the working folder with the repository as a whole, and branch out its options exclusively within its history.

Normally, you can see two versions of a folder from one such repository on the disk at the same time - you can only copy the working folder in the state of one version, and then switch the working folder to display another version (= take another version from the local repository). Although it is more concerned with git - because in hg, judging by the comments, and by rg03.wordpress.com/2009/04/07/mercurial-vs-git - to work with the timeline, the entire repository is often (?) Cloned, and it is in the next folder. For the repository - he himself is a working folder. A sort of "working folder on steroids." (It is interesting how development environments react to the movement of working library folders, which are configured to search for library source codes for specific paths of the main working folder? Or do they not happen on a unix way?)

And the access rights are only to the repository as a whole, using file system tools, or handles to write procedural hacks, which will reject some of the edits sent from another repository that do not suit the owner of this repository. Now they are thinking about how to catch up - HG makes subrepos, for example ...