5 ms·

It's not centralized.

by mtts 15y ago

marshray 15y ago
I've used centralized SCCSs for years and years. I guess I don't see why you can't use git as one, just have everybody agree to push to a central repository on a server. There is the issue of the size of the local copy, but it doesn't seem to be a big deal in practice. I just don't check in the heavyweight frameworks as vendor drops into the same repos as I use for my own, smaller, codebase. Granted, I'm scared to death of ending up in a merge-gone-wrong hell situation trying to do stuff that I'm very familiar with in Perforce. But I'm happy being a git newb taking baby steps a bit longer.
- rimantas 15y ago
  There is no issue with the size of the local copy. Most of the times the entire git repo is smaller than single SVN checkout.
  - nirvdrum 15y ago
    I don't think I've ever seen a situation where that's true. And I've converted a lot of repositories (I maintain the svn2git project). SVN has its metafiles, but git has the full history locally. In all but the most trivially-sized projects, the git clone is bound to be larger. For larger projects it can be several orders of magnitude larger.
    - rimantas 15y ago
      Git also has much more efficient storage mechanism.
      - nirvdrum 15y ago
        I'm aware of that and didn't imply otherwise. But the storage mechanism is for the history, not for the materialized files in the working directory. That's going to be the same for either git or SVN, since they're checked out. So you're talking about comparing git's history DB to SVN's metadata files. The metadata files are effectively constant cost whereas the git history grows with each checkin. They get quite large.
    - fanf2 15y ago
      I have here a svn checkout of the FreeBSD HEAD branch, using 1550 MB disk in 199443 files. I also have a git checkout of the same thing, which includes the history of the HEAD but not the other branches. It is 1234 MB in 54823 files.
  - marshray 15y ago
    An up-to-date snapshot of my source tree at work is several GB. The whole Perforce repo is probably 100GB. Most of that is vendor libraries. For example, every so often we update to a new version of the Boost C++ libraries and pre-build it for most common platforms. This amounts to a GB or two. This is easier on the other developers and it makes the process more repeatable for QA. One of the great things about Perforce is that it's normal practice to map only selected subtrees of the repo. So I have several workspaces going at any one time. As much as I am impressed with git's speed, this would not work with git. I used to try to managing Boost's vendor drop as a git repo. I now just keep my notes in there about how to download and build it locally.
    - MattRogish 15y ago
      I think the idea is to use git submodules for vendor libs. Anything you're not modifying and a 3rd party is maintaining should be a submodule; that way you don't keep any of those changes in the repo.
      - marshray 15y ago
        When a new vendor release comes out, we build it with our "official" compiler settings for the different platforms, branch the headers from the source and combine them into a convenient "SDK" tree, sometimes tweak something here or there, and update the document. Amounts to several GB being checked in from multiple machines. Occasionally a developer (usually me, but others too) needs to commit changes back to our central repo vendor tree. I suppose we could do that into a separate repository and then define parts of that as a git submodule. Hmm, reading http://book.git-scm.com/5_submodules.html http://book.git-scm.com/5_submodules.html I don't see how to do that with git without using 100 GB on the library dev machines.
- mtts 15y ago
  You can, but SVN more or less forces you to.
  - marshray 15y ago
    Which means that if a developer wants to do do git-like stuff (say sharing a patch with a single other developer or committing a day's unfinished work to an alternate backup site), then he's just going to have to work around the SVN tool to do it. The tool should exist to serve the people producing the work, not the other way around.

It's not centralized.

by mtts 15y ago

It's not centralized.

I've used centralized SCCSs for years and years. I guess I don't see why you can't use git as one, just have everybody agree to push to a central repository on a server. There is the issue of the size of the local copy, but it doesn't seem to be a big deal in practice. I just don't check in the heavyweight frameworks as vendor drops into the same repos as I use for my own, smaller, codebase. Granted, I'm scared to death of ending up in a merge-gone-wrong hell situation trying to do stuff that I'm very familiar with in Perforce. But I'm happy being a git newb taking baby steps a bit longer.

rimantas 15y ago
There is no issue with the size of the local copy. Most of the times the entire git repo is smaller than single SVN checkout.
- nirvdrum 15y ago
  I don't think I've ever seen a situation where that's true. And I've converted a lot of repositories (I maintain the svn2git project). SVN has its metafiles, but git has the full history locally. In all but the most trivially-sized projects, the git clone is bound to be larger. For larger projects it can be several orders of magnitude larger.
  - rimantas 15y ago
    Git also has much more efficient storage mechanism.
    - nirvdrum 15y ago
      I'm aware of that and didn't imply otherwise. But the storage mechanism is for the history, not for the materialized files in the working directory. That's going to be the same for either git or SVN, since they're checked out. So you're talking about comparing git's history DB to SVN's metadata files. The metadata files are effectively constant cost whereas the git history grows with each checkin. They get quite large.
  - fanf2 15y ago
    I have here a svn checkout of the FreeBSD HEAD branch, using 1550 MB disk in 199443 files. I also have a git checkout of the same thing, which includes the history of the HEAD but not the other branches. It is 1234 MB in 54823 files.
- marshray 15y ago
  An up-to-date snapshot of my source tree at work is several GB. The whole Perforce repo is probably 100GB. Most of that is vendor libraries. For example, every so often we update to a new version of the Boost C++ libraries and pre-build it for most common platforms. This amounts to a GB or two. This is easier on the other developers and it makes the process more repeatable for QA. One of the great things about Perforce is that it's normal practice to map only selected subtrees of the repo. So I have several workspaces going at any one time. As much as I am impressed with git's speed, this would not work with git. I used to try to managing Boost's vendor drop as a git repo. I now just keep my notes in there about how to download and build it locally.
  - MattRogish 15y ago
    I think the idea is to use git submodules for vendor libs. Anything you're not modifying and a 3rd party is maintaining should be a submodule; that way you don't keep any of those changes in the repo.
    - marshray 15y ago
      When a new vendor release comes out, we build it with our "official" compiler settings for the different platforms, branch the headers from the source and combine them into a convenient "SDK" tree, sometimes tweak something here or there, and update the document. Amounts to several GB being checked in from multiple machines. Occasionally a developer (usually me, but others too) needs to commit changes back to our central repo vendor tree. I suppose we could do that into a separate repository and then define parts of that as a git submodule. Hmm, reading http://book.git-scm.com/5_submodules.html http://book.git-scm.com/5_submodules.html I don't see how to do that with git without using 100 GB on the library dev machines.
mtts 15y ago
You can, but SVN more or less forces you to.
- marshray 15y ago
  Which means that if a developer wants to do do git-like stuff (say sharing a patch with a single other developer or committing a day's unfinished work to an alternate backup site), then he's just going to have to work around the SVN tool to do it. The tool should exist to serve the people producing the work, not the other way around.