4 ms·

* until you work on a project which has a 9Gb repo and history...

by cssmoo 12y ago

makmanalp 12y ago
You can do a shallow clone in any reasonable versioning system: http://stackoverflow.com/questions/6941889/is-git-clone-depth-1-shallow-clone-more-useful-than-it-makes-out http://stackoverflow.com/questions/6941889/is-git-clone-dept...
- samastur 12y ago
  But then git blame or bisect don't really work anymore.
  - Tobani 12y ago
    It may work well enough.
  - IanCal 12y ago
    I'm not too sure what could be realistically done to implement offline bisect without getting the all the history you care about.
    - ufo 12y ago
      One approach would be to query the server for these operations. And unlike what happens in Git, where blame is an O(N) operation, a centralized server is free to spend some extra storage to add some caches or indexes to make these searches faster.
      - IanCal 12y ago
        Querying the server rarely works when you're offline.
- CHY872 12y ago
  but then you lose the ability to git bisect, blame etc, which is the root comment's advantage of doing git. I've worked on a project where the git repository was man gigabytes - because at some point someone decided to put some binary files in the repository, which periodically got updated - now years on the repository's about 10GB, and you can't really delete the stuff clogging it up without rewriting history from years prior and making the 200 devs life hell. Importantly, you do need all that history, because there are commits from the same time that are relevant.
deleted 12y ago
[deleted]
Semiapies 12y ago
And if you never do, even after fifteen years working dozens of different project? Including a few projects that have run for most of those fifteen years? I agree that git is weak for binaries, but the only binaries I need to keep in it are a few images and installer - nothing that has many versions, nothing that causes me problems. Similarly, a lot of open source software is mostly made up of code, not blobs. As for distributed work, even when I'm the only developer on a project, it helps not to have to worry about a central server, especially if I'm on-site. It's also hugely faster than SVN ever was.
JoachimS 12y ago
9 Gbit really aint that much.
- lutorm 12y ago
  Ours is 370GB. git-svn typically falls over and dies on that, if you're brave enough to try.
  - Crito 12y ago
    370GB is peanuts. Try keeping a centralized version control server up and operating when you have dozens of terabytes and thousands of developers. Better to abandon the ultimately doomed monolithic repo scheme and tool your build and deployment systems to expect a multi-repo ecosystem. Then allow your teams to create their own repos on the fly, one for each individual project if they please. Once you reach that point, there is little reason to not use a more sensible VCS like hg or git.

* until you work on a project which has a 9Gb repo and history...

by cssmoo 12y ago

* until you work on a project which has a 9Gb repo and history...

You can do a shallow clone in any reasonable versioning system: http://stackoverflow.com/questions/6941889/is-git-clone-depth-1-shallow-clone-more-useful-than-it-makes-out http://stackoverflow.com/questions/6941889/is-git-clone-dept...

samastur 12y ago
But then git blame or bisect don't really work anymore.
- Tobani 12y ago
  It may work well enough.
- IanCal 12y ago
  I'm not too sure what could be realistically done to implement offline bisect without getting the all the history you care about.
  - ufo 12y ago
    One approach would be to query the server for these operations. And unlike what happens in Git, where blame is an O(N) operation, a centralized server is free to spend some extra storage to add some caches or indexes to make these searches faster.
    - IanCal 12y ago
      Querying the server rarely works when you're offline.
CHY872 12y ago
but then you lose the ability to git bisect, blame etc, which is the root comment's advantage of doing git. I've worked on a project where the git repository was man gigabytes - because at some point someone decided to put some binary files in the repository, which periodically got updated - now years on the repository's about 10GB, and you can't really delete the stuff clogging it up without rewriting history from years prior and making the 200 devs life hell. Importantly, you do need all that history, because there are commits from the same time that are relevant.

deleted 12y ago

[deleted]

Semiapies 12y ago

And if you never do, even after fifteen years working dozens of different project? Including a few projects that have run for most of those fifteen years? I agree that git is weak for binaries, but the only binaries I need to keep in it are a few images and installer - nothing that has many versions, nothing that causes me problems. Similarly, a lot of open source software is mostly made up of code, not blobs. As for distributed work, even when I'm the only developer on a project, it helps not to have to worry about a central server, especially if I'm on-site. It's also hugely faster than SVN ever was.

JoachimS 12y ago

9 Gbit really aint that much.

lutorm 12y ago
Ours is 370GB. git-svn typically falls over and dies on that, if you're brave enough to try.
- Crito 12y ago
  370GB is peanuts. Try keeping a centralized version control server up and operating when you have dozens of terabytes and thousands of developers. Better to abandon the ultimately doomed monolithic repo scheme and tool your build and deployment systems to expect a multi-repo ecosystem. Then allow your teams to create their own repos on the fly, one for each individual project if they please. Once you reach that point, there is little reason to not use a more sensible VCS like hg or git.