5 ms·

Yeah, I just picked up git about 3 years ago and I probably wouldn't even take a job if they were using one of the other DVCSs.

by joeblau 12y ago

delive 12y ago
I've been using git-svn for workflow the past 2 years or so. It's not perfect, but it seems to cover all the use cases I've had and integrates well with the regular svn workflow.
eddieroger 12y ago
I really hope you're being sarcastic. If you're turning a job down because of the VCS, hopefully you've got a surplus of work to choose from.
- zbowling 12y ago
  engineers do in the bay area.
  - balls187 12y ago
    and in seattle
- zellyn 12y ago
  I understand the sentiment: the fact that a company uses Visual Sourcesafe, or ClearCase, or something else terrible tells you a lot about their culture.
- throwaway5752 12y ago
  I'd be inclined to agree with you in some cases ("any port in a storm"), but otherwise I would view a VSS or ClearCase shop as one that's possibly on the wrong side of the technology curve. I have worked with VSS, p4, cvs, svn, hg, and git (and arms length with evil things like ClearCase and more primitive stuff like RCS). Everyone should have an idea of the minimal toolchain they want to work with. But that aside.. massive props to the Git team on 2.0!
  - zimpenfish 12y ago
    First month at the previous gig was spent writing an SVN-based implementation of SCCS because their workflow required SCCS locking etc. and they wanted to move the backend to SVN for the eventual "moving the developers to not all working in the same directory" project. It was a very tearful month.
damncabbage 12y ago
I can almost understand with something like Subversion (which seems to subtly skew the entire development process to work around the friction some of its basic operations introduce), but not even Mercurial? :(
- joeblau 12y ago
  Not even Mercurial :) Haha j/k I actually don't mind Mercurial, but I'd still rather work with git.
  - crdoconnor 12y ago
    They're essentially identical. Mercurial just has slightly easier to understand syntax and and a cultural bias against rebasing.
    - anton_gogolev 12y ago
      Nope. Mercurial devs rebase heavily during Mercurial development, for instance. It's Changeset Evolution [1] that makes history rewriting _safe_. [1]: http://mercurial.selenic.com/wiki/ChangesetEvolution http://mercurial.selenic.com/wiki/ChangesetEvolution
malkia 12y ago
A lot of game studios use Perforce (p4) - while it's not distributed, it seems to be easier to non-programming folks - artists, producers, etc. And git can still be used along with it - For some of the lib/tools that I do, I create a ".git" repository living along with p4, and work like this - then submit in P4.
- SoftwareMaven 12y ago
  Perforce also handles large binary blobs better as well, which is super important in game programming.
  - yoklov 12y ago
    Where I work (game company with about 20 people) we solve this by versioning unimported assets separately (in svn, because that's what we used before git). We bring them into the git repo after running them through our asset pipeline, which means that there are really never any merge conflicts for them and every checkout is a playable version of the game with art. This reduces the load on git by a lot, though we still tend to have .git folders measured in the tens of gigabytes, which is getting up there.
- zanny 12y ago
  How is git with a gui hard for artists? I get that they don't want to stage their changes and commit them from a terminal, but you literally just pick your files and write a note about what you did before hitting the commit button.
  - rtpg 12y ago
    I think perforce deals with binary files better too (not sure of the details)
  - virtue3 12y ago
    git does have very very bad binary asset management. It doesn't really work like svn/perforce in a logical tree structure and each commit has it's own hash and isn't necessarily ordered so there ends up being a _lot_ of copies of binary assets (git -unconfigured- will attempt to store deltas between changes but it can't do that with binary assets... and over time gets _very_ slow with large binary assets). This isn't necessarily horrid for web apps as the images aren't big. But when you're talking about 500mb PSD files and massive massive 3d maya/max scenes it's horrid. http://stackoverflow.com/questions/3055506/git-is-very-very-slow http://stackoverflow.com/questions/3055506/git-is-very-very-...
Walkman 12y ago
> I probably wouldn't even take a job if they were using one of the other DVCSs. Why? At my current workplace, I converted a svn repository (with 6 years of commits) to git without any hiccups! I did not even lost a single commit! I also detached a huge binary directory (they committed everything to svn...) and made a different repo for it. Also you got git-svn, with you can seamlessly commit to an svn repo and still work in git on your local machine, nobody will notice, except you!
deleted 12y ago
[deleted]

Yeah, I just picked up git about 3 years ago and I probably wouldn't even take a job if they were using one of the other DVCSs.

by joeblau 12y ago

Yeah, I just picked up git about 3 years ago and I probably wouldn't even take a job if they were using one of the other DVCSs.

delive 12y ago

I've been using git-svn for workflow the past 2 years or so. It's not perfect, but it seems to cover all the use cases I've had and integrates well with the regular svn workflow.

eddieroger 12y ago

I really hope you're being sarcastic. If you're turning a job down because of the VCS, hopefully you've got a surplus of work to choose from.

zbowling 12y ago
engineers do in the bay area.
- balls187 12y ago
  and in seattle
zellyn 12y ago
I understand the sentiment: the fact that a company uses Visual Sourcesafe, or ClearCase, or something else terrible tells you a lot about their culture.
throwaway5752 12y ago
I'd be inclined to agree with you in some cases ("any port in a storm"), but otherwise I would view a VSS or ClearCase shop as one that's possibly on the wrong side of the technology curve. I have worked with VSS, p4, cvs, svn, hg, and git (and arms length with evil things like ClearCase and more primitive stuff like RCS). Everyone should have an idea of the minimal toolchain they want to work with. But that aside.. massive props to the Git team on 2.0!
- zimpenfish 12y ago
  First month at the previous gig was spent writing an SVN-based implementation of SCCS because their workflow required SCCS locking etc. and they wanted to move the backend to SVN for the eventual "moving the developers to not all working in the same directory" project. It was a very tearful month.

damncabbage 12y ago

I can almost understand with something like Subversion (which seems to subtly skew the entire development process to work around the friction some of its basic operations introduce), but not even Mercurial? :(

joeblau 12y ago
Not even Mercurial :) Haha j/k I actually don't mind Mercurial, but I'd still rather work with git.
- crdoconnor 12y ago
  They're essentially identical. Mercurial just has slightly easier to understand syntax and and a cultural bias against rebasing.
  - anton_gogolev 12y ago
    Nope. Mercurial devs rebase heavily during Mercurial development, for instance. It's Changeset Evolution [1] that makes history rewriting _safe_. [1]: http://mercurial.selenic.com/wiki/ChangesetEvolution http://mercurial.selenic.com/wiki/ChangesetEvolution

malkia 12y ago

A lot of game studios use Perforce (p4) - while it's not distributed, it seems to be easier to non-programming folks - artists, producers, etc. And git can still be used along with it - For some of the lib/tools that I do, I create a ".git" repository living along with p4, and work like this - then submit in P4.

SoftwareMaven 12y ago
Perforce also handles large binary blobs better as well, which is super important in game programming.
- yoklov 12y ago
  Where I work (game company with about 20 people) we solve this by versioning unimported assets separately (in svn, because that's what we used before git). We bring them into the git repo after running them through our asset pipeline, which means that there are really never any merge conflicts for them and every checkout is a playable version of the game with art. This reduces the load on git by a lot, though we still tend to have .git folders measured in the tens of gigabytes, which is getting up there.
zanny 12y ago
How is git with a gui hard for artists? I get that they don't want to stage their changes and commit them from a terminal, but you literally just pick your files and write a note about what you did before hitting the commit button.
- rtpg 12y ago
  I think perforce deals with binary files better too (not sure of the details)
- virtue3 12y ago
  git does have very very bad binary asset management. It doesn't really work like svn/perforce in a logical tree structure and each commit has it's own hash and isn't necessarily ordered so there ends up being a _lot_ of copies of binary assets (git -unconfigured- will attempt to store deltas between changes but it can't do that with binary assets... and over time gets _very_ slow with large binary assets). This isn't necessarily horrid for web apps as the images aren't big. But when you're talking about 500mb PSD files and massive massive 3d maya/max scenes it's horrid. http://stackoverflow.com/questions/3055506/git-is-very-very-slow http://stackoverflow.com/questions/3055506/git-is-very-very-...

Walkman 12y ago

> I probably wouldn't even take a job if they were using one of the other DVCSs. Why? At my current workplace, I converted a svn repository (with 6 years of commits) to git without any hiccups! I did not even lost a single commit! I also detached a huge binary directory (they committed everything to svn...) and made a different repo for it. Also you got git-svn, with you can seamlessly commit to an svn repo and still work in git on your local machine, nobody will notice, except you!

deleted 12y ago

[deleted]