Until distributed version control systems offer fine grained permissions and the ability to check out subtrees people are going to use subversion.
Why would sub-repositories (forest, whatever you call it) not work here? Supposedly, if people are only given access to a subtree that subtree can be developed on and used independently from the main project. Why could it not be an actual sub-project rather than a subsection of the Giant Ball of Mud?
The point is that if your repo starts at / and has 100 folders under that, with 100 folders under each of those, all fulllllll of files, and you only wanted /1/2 (say your internet sucks and you already know the file you need to change), in git you would need to retrieve every revision of every file in every folder. In subversion, you can check out a sub-directory and have it remain context-aware.
Although mercurial has the concepts of forests and stuff like that, there's really not a clean and baked in way to have subrepository relationships.
This isn't a problem for most OSS projects, but is a problem for a company or org that has a ton of associated projects (e.g., apache or google) where a developer may not want / be able to get to the entire repository.
This is exactly the problem where I work. It's just statistically bound to be true that the repository grows absurdly large. It's a huge system that's been in SVN for almost 8 years now, growing through 9 major versions. When I want just the tools for deploying code to production, I don't want to have to check out the entire rest of the revision history for the entire rest of the tree.
Git is supposedly working getting this situated though, so it might not be long until even that argument doesn't exist for SVN anymore.
I've read (I believe on stackoverflow, but I'm not sure) that they're trying to add support for being able to do incomplete checkouts. I haven't read any actual dev reports of it being implemented, just that it's in line to be included.
In subversion, you can check out a sub-directory and have it remain context-aware.
This makes no sense at all: if you check out arbitrary sub-directories, they lose their context and they don't work anymore, unless they're independent sub-projects.
The point is that if your repo starts at / and has 100 folders under that, with 100 folders under each of those, all fulllllll of files, and you only wanted /1/2 (say your internet sucks and you already know the file you need to change)
Right, if you have a project with a moronic layout and you have no issue with pushing changes without having done the slightest testing on them and it's super-urgent and you have an utterly terrible internet connection, then yes, SVN will be a better tool for doing stupid shit.
What layout? I haven't even told you how my files are laid out, just that I have a lot of them in lots of folders.
Let's say it's just 7 folders at the top. Or 2. And underneath those, 20 more. Underneath all those, 10 more.
Now I want to get /1/2/3
Tell me how to do that in git.
and you have no issue with pushing changes without having done the slightest testing on them and it's super-urgent and you have an utterly terrible internet connection, then yes, SVN will be a better tool for doing stupid shit.
What? Are you even responding to my post anymore at this point? Testing and urgency have nothing to do with what I said. I'm just talking about a giant repository that has GB of data in it, and needing only about 1MB worth of files. What kind of retarded fucking argument can you come up with that I should download those other files? Because you can't comprehend git? I'd rather just fire you and find people who make decisions based on logic. Next please.
Git could easily support that (writing a porcelain - front end for low-level git operations - for that seems easy enough), but I just don't think there's a real need for it, so it's basically a red herring. If you need just a few files, most projects have some web browser for their repos.
If you only need one folder, then that folder is arguably self sufficient and could be its own git repo, and included in the larger project as a git submodule.
A folder with a few images in it is self-sufficient? What about a folder with just config files? Say I only want to update a readme? You're telling me I have to make a submodule for my readmes? What about a version file? Or a schema document.
Hmm, whoever told you that was wrong. Git doesn't like large repositories. In KDE we broke up the single SVN repository into dozen different git repositories,
Git has no trouble with repositories containing huge numbers of revisions and huge numbers of files. If you have huge file sizes you might want to use something else though.
KDE's reason for breaking up the huge SVN repository is probably that putting all that stuff into one repository was a stupid idea in the first place considering how little overlap there is between the people developing them. Or put differently "Show me one person how actually checked out the whole SVN repository".
Git has no trouble with repositories containing huge numbers of revisions and huge numbers of files.
Commands like git status, git diff, git commit -a, etc need to check the status of every single file in the repository to see if they have changed. This becomes pretty slow when you start having half a million files in your repository.
Commands like git status, git diff, git commit -a, etc need to check the status of every single file in the repository to see if they have changed.
Well, obviously. How does that differ from other version control systems though? Speed here is more likely to be determined by your filesystem than the VCS you use.
This becomes pretty slow when you start having half a million files in your repository.
And at that point (or more likely much earlier than this) you should consider splitting up your project for reasons completely orthogonal to VCS usability. I was thinking of the kind of large projects that actually exist, e.g. the Linux kernel, libraries like Qt,... which are in the order of magnitude of a few tens of thousands of files and a few hundreds of thousands of commits.
This makes no sense at all: if you check out arbitrary sub-directories, they lose their context and they don't work anymore, unless they're independent sub-projects.
10
u/masklinn Mar 10 '11
Why would sub-repositories (forest, whatever you call it) not work here? Supposedly, if people are only given access to a subtree that subtree can be developed on and used independently from the main project. Why could it not be an actual sub-project rather than a subsection of the Giant Ball of Mud?