8 ms·

Why is Git better than Subversion?

47 points by d99kris 13y ago

yoha 13y ago
> This looks good at first, but just keep in mind the added complexity to this approach. I think this is not exactly right. The approach is fundamentally different but not more complicated. I think that the one important concept of Git is that everyone has a complete copy repository, making the communication with a server (through SSH, HTTP or the Git protocol) just an additional feature: the very core of Git does not depend on anything.
- egil 13y ago
  It is also important to note that the git tooling has matured a lot over the years. In the beginning, people used wrappers such as Cogito - "Human-suitable Interface for Git"[1] because the command line interface was such a pain. [1] http://git.or.cz/cogito/ http://git.or.cz/cogito/
- einhverfr 13y ago
  It is more complicated, and the complexity buys you (assuming you need it) an ability to relax certain limits of more traditional SCM solutions. To be honest I don't find git to be better than svn for a lot of work, having worked with both. There are fundamentally different decisions made, such as: 1 it is a lot easier to forget to add a file in svn, but it is a lot easier to accidentally include a file you don't want in git. 2 workflow in svn is a lot more streamlined because you aren't dealing with a multi-stage synchronization between your repositories (I am assuming the reason you use version control is in part to collaborate). Now, one thing I have started to get really into has been the combination of github and svn, which gives you a lot of the benefits of svn and git together. Now, it doesn't give you every benefit of git but it gives you enough of them to make things easier all around in many cases.
  - chris_wot 13y ago
    I really don't understand why you believe it's more complicated. Why do you say that?
    - einhverfr 13y ago
      ok: Workflow with svn: 1. Edit some files. 2. svn commit -m "commit message" (ok, I add an svn up && before, but I consider that one step). done Workflow with git: 1. Edit some files 2. git commit 3. Review the message to see which files I actually want to add, if there is anything that needs to go into git ignore, etc. 4. Edit .gitignore as necessary 5. git add * 6. git commit -m "commit message" 7. git push So for simple cases you have 3 times as many steps, for more complex cases you have more steps. Note that I usually push/pull from my own github repo and not a central one because that avoids a lot of other hassle (and then use pull requests for managing inter-repo changes, something github has done a nice job with). Additionally absent this you have a significant likelihood that you end up with various files that aren't a part of your build environment (generated makefiles, backups of generated makefiles, built packages, etc) accidently pushed out to your central repo.
      - adekok 13y ago
        Only if you make git that complicated. Steps 2-6 can be replaced with: git commit -m "commit message" file1 file2 ... When you use a tool inefficiently, don't blame the tool.
        einhverfr 13y ago
        That's still a lot more verbose than svn and even if you do that, you still have only managed to reduce the number of commands required from 3x to 2x what svn requires. Also wouldn't you agree that git has a much steeper learning curve than svn? What is this due to if not the added complexity?
        janvidar 13y ago
        1) Edit some files 2) git commit -a -m "blah blah" 3) git push So, it adds one extra command to push things to an upstream git repository. But, this is the nature of being decentralized.
jmnicolas 13y ago
Before even clicking the SO link, I knew this question was closed as off-topic ... How about they make a dedicated space in SO where this kind of questions are allowed. I don't mean a free for all, but a heavily moderated part where you can ask recommendations from your peers about the best framework / book etc as long as it's related to programming.
- viraptor 13y ago
  It's been there for ages: http://programmers.stackexchange.com/ http://programmers.stackexchange.com/ Edit: Although it would be great if SO suggested moving discussions there, instead of just closing as off-topic. You can close-move questions that belong to superuser.com for example.
  - etler 13y ago
    Why don't they move the question instead of just closing it?
    - viraptor 13y ago
      You've got very limited options when moderating SO unfortunately. When you want to mark the post as belonging to other SE site, the only options are: - meta.stackoverflow.com - superuser.com - tex.stackexchange.com - dba.stackexchange.com - sharepoint.stackexchange.com Which is an... interesting set of choices. I'm not sure why you can't suggest others. I'd really like to migrate to programmers.SE. Otherwise the only option is to actually close as off-topic.
      - ygra 13y ago
        THe list of choices you can vote to move to is based on where questions are migrated most of the time. Moderators can still move the question wherever they want, just flag for attention and give a custom message to that effect.
        13y ago
deleted 13y ago
[deleted]
deleted 13y ago
[deleted]
chris_wot 13y ago
Wow, the first answer is so... clueless! Git seems to be the "new, shiny, cool" thing. ... As said above: Git adds complexity. Two modes of creating repositories, checkout vs. clone, commit vs. push... You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository"). ... Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written). Perhaps that is a little harsh. I think the poster just doesn't understand DVCS's.
- m_mueller 13y ago
  Could you explain what's wrong with that answer? I found it to be spot on, but then again maybe I'm 'clueless' as well.
  - chris_wot 13y ago
    The whole point of a DVCS is to be decentralized. Linus Torvalds often just posts his own repository and others pull from it. You can use it as a centralized repo, and it works quite well. In fact, it's how I'm doing development with LibreOffice via gerrit. However, even there I find it easier. I find my workflow is to work on a branch, make sure I have clean commits (I use rebase pretty frequently) and branch and merge often. Frankly, it's easier to work with. I find the staging model to be really excellent, and find it just easier to move up and down commits. But looking at the quotes: Git seems to be the "new, shiny, cool" thing. No, no it's not. Two modes of creating repositories Well, sure. It's literally just a shortcut for setting up groups and then changing a global setting. Repos can go from bare to shared reasonably easily. I fail to see the point. checkout vs. clone Checkout checks out a branch of path to the working directory. Clone gets an entire repository and "clones" it to the current directory. There is no "versus" here, they are two completely different operations. commit vs. push Commit records the changes to the local repository. Push basically takes a ref (a mapping to a sha-1 value that identifies a commit in the tree) and updates a ref in a remote repository. In essence, you are pushing your changes to the remote repository. Again, the thinking of a VCS person, not someone used to DVCSes. You have to know which commands work locally and which work with "the server" Only if you think in terms of centralized repositories. A DVCS is distributed. It's a completely different way of thinking. I find it superior in very many ways. Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. The whole point of git is that you have your version, and you either pull from or push to different repositories and and when needed. The whole idea of centralization is not core to it at all.
flaxin 13y ago
- why is the sky blue? - why do birds sing in the morning? here's why from G-O-D itself: http://www.youtube.com/watch?v=4XpnKHJAok8 http://www.youtube.com/watch?v=4XpnKHJAok8
- atmosx 13y ago
  I was curious to see if anyone posted this already :-) Awesome talk by my favorite programmer :-P
  - deleted 13y ago
    [deleted]
badman_ting 13y ago
Judgment is not the end of the world, and it is not a reflection upon one's character to say that something is better than the tool one currently uses. In other words, it's alright to say that git is better than SVN. If it weren't we wouldn't have all stopped using SVN.
- pessimizer 13y ago
  >If it weren't we wouldn't have all stopped using SVN. I like git fine, but judging quality by where the crowd is running is like flipping a coin. edit: Fine. We're just going to substitute pith for basic reason here, I guess. Because the industry has largely moved to git, it's clearly the superior tool, and those who don't accept that are clearly emotionally blocked. Or not.
- skore 13y ago
  In Linus Torvalds' talk on git at google[0], he mentions that the reason why he did not choose SVN (one of the reasons why he saw no other way but to build GIT) was that SVNs mission statement read "To create a compelling replacement for CVS"... which Linus hated with a passion and thus could not see why he would even use "a compelling replacement" of. Interestingly enough, in the 'Open Source projects and poisonous people' talk[1] with two SVN developers, they mention how they chose that line specifically to make sure that everybody is on the same page with the scope of the project - improving upon what people knew and were used to instead of wild, new things. Specifically because they would often have people come into the community with some grand plans that would have just exploded the scope. It is of course arguable to what extent there could be a general rule to this, but in this case, GIT is just so fundamentally and obviously the better option than SVN. Had somebody tried to make SVN into GIT, it would have simply killed SVN, so it was the right course of action to make it a new project. SVN was destined to die by its design. To see the GIT adoption rates these days (particularly due to tools like GitHub) is very encouraging to people who like to think that sometimes, starting over fresh is the only option. Of course, the thing you want to build really has to be that much better than the old thing you're trying to replace. So I agree with you - it's alright to say that GIT is better than SVN. The crucial point to me, though, is that it is so much better. So much better that it is worth the effor to build and worth the effort of the community to switch. [0] https://www.youtube.com/watch?v=4XpnKHJAok8 https://www.youtube.com/watch?v=4XpnKHJAok8 [1] https://www.youtube.com/watch?v=-F-3E8pyjFo https://www.youtube.com/watch?v=-F-3E8pyjFo
wila 13y ago
The question is about two -now old- versions of version control software systems, the question was asked five years ago. Both systems have matured quite a bit making the comments less accurate to actually base an opinion upon.
grexi 13y ago
For all Git users which hate SVN branching - I've added this small shell extension last year: https://github.com/grexi/snippets/tree/master/svnaliases https://github.com/grexi/snippets/tree/master/svnaliases
benihana 13y ago
Why is iOS better than Android? Why is Linux better than OS X? Why is BMW better than Mercedes? Why are Pink Lady apples better than Granny Smith apples? Why is being an omnivore better than being a vegetarian? The way you answer all these questions will be the same. So whether you have an answer or a process to answer these questions, you'll have a pretty good idea about git vs svn.
- Goladus 13y ago
  The form of the answer may be the same, but not the content. The idea that answers are subject to preference and different needs doesn't mean a question can not have objective answers.
nahname 13y ago
The second answer is pretty good. Benefits: -Works offline -Branches/Merging -Fork another's work -Collaboration -Light weight and fast -Flexible -Tooling (github) Drawbacks of Git: -Hard to learn if you know a centralized SCM.
- kyrra 13y ago
  Drawback: if you are storing a lot of binary blobs, it will balloon the size of a git repo quickly if those objects change often. While with SVN, users only have to download the latest. To add: there is a reason most game development shops use Perforce. Sometimes you have to deal with large binary assets. Git is just the wrong answer in that case.
GoldenMonkey 13y ago
Choose the right tool for the job. Git is the right tool for: branching and merging. And for cherry picking bug fixes from disparate branches. The git workflow revolves around creating a branch for a feature or bug fix. Because in Git, branching and merging is cheap. I've switched from a decade of using SVN, to Git and it is more than a shiny new tool. It is the right kind of tool for the above. In SVN, branching and merging is expensive, and if the changes between branches were extensive enough.. the merge process would take a good weekend of manual effort. In some scenarios almost impossible to do. And in some shops I worked at, a branch with 3 months of differences would take a week to merge. SVN is not the right tool for this.
- T-hawk 13y ago
  By contrast, my job is a much better usage case for SVN. We have only three developers, a single trunk, and rolling production deployments. We're never concerned about release or feature branches or back-porting fixes. SVN is the right tool for this. Git's extra abstraction layer around decentralization and distribution would just get in the way. I have used git in a previous job and for personal projects to get something up on Github, and I haven't yet missed it here in our SVN shop. Git is like applying an N log N solution to an algorithmic problem. Great for something that in the naive case would be N² (N branches exchanging updates with each of N branches), but when the problem space is very small, whatever layer represents the log N is just overhead.
  - sampo 13y ago
    Nowadays you use Github with SVN, too, if you like.
  - FeloniousHam 13y ago
    Even as a single developer, I find the effortless branching in git a killer feature. Even with the poor (from a human perspective) implementation of EGit in Eclipse, the ability to experiment in branches while preserving a "last known good" point would be hard to give up. Add to this the effortless sharing and "cost-less" review provided make git a clear winner.
DougN7 13y ago
Serious question: How/where do you check in your binary builds and debug symbols if you use git? I've read it's not great at some not-so-large project size. I'm using SVN on a micro-sized team with binaries from all released builds safely checked in (which means the repository is probably 100GB-ish in size), and it works great. [and to head off the argument - rebuilding from source is not an option when you have to diagnose a customer crash when they are using a 3 year old build of the software - you'd have to archive a build machine to even have a chance...]
- fournm 13y ago
  Why are your binary builds living in version control?
  - chris_wot 13y ago
    That is the right question!
  - DougN7 13y ago
    Why wouldn't they? Conveniently and safely in the same location as the code they were built with. Tagged the same way. Having a separate repository is just inviting trouble down the road, no?
    - fournm 13y ago
      Because they're binary files, used entirely for archival purposes. They shouldn't be changing, they shouldn't have "versions" that are anything to deal with meaningfully as far as your repository is concerned. They should be in flat storage somewhere, with some directory or file name scheme that makes sense based on your version numbers / builds / what have you. Backed up, (ideally) with hashes that verify that they're the same file they once were.

47 points by d99kris 13y ago

yoha 13y ago

> This looks good at first, but just keep in mind the added complexity to this approach. I think this is not exactly right. The approach is fundamentally different but not more complicated. I think that the one important concept of Git is that everyone has a complete copy repository, making the communication with a server (through SSH, HTTP or the Git protocol) just an additional feature: the very core of Git does not depend on anything.

egil 13y ago
It is also important to note that the git tooling has matured a lot over the years. In the beginning, people used wrappers such as Cogito - "Human-suitable Interface for Git"[1] because the command line interface was such a pain. [1] http://git.or.cz/cogito/ http://git.or.cz/cogito/
einhverfr 13y ago
It is more complicated, and the complexity buys you (assuming you need it) an ability to relax certain limits of more traditional SCM solutions. To be honest I don't find git to be better than svn for a lot of work, having worked with both. There are fundamentally different decisions made, such as: 1 it is a lot easier to forget to add a file in svn, but it is a lot easier to accidentally include a file you don't want in git. 2 workflow in svn is a lot more streamlined because you aren't dealing with a multi-stage synchronization between your repositories (I am assuming the reason you use version control is in part to collaborate). Now, one thing I have started to get really into has been the combination of github and svn, which gives you a lot of the benefits of svn and git together. Now, it doesn't give you every benefit of git but it gives you enough of them to make things easier all around in many cases.
- chris_wot 13y ago
  I really don't understand why you believe it's more complicated. Why do you say that?
  - einhverfr 13y ago
    ok: Workflow with svn: 1. Edit some files. 2. svn commit -m "commit message" (ok, I add an svn up && before, but I consider that one step). done Workflow with git: 1. Edit some files 2. git commit 3. Review the message to see which files I actually want to add, if there is anything that needs to go into git ignore, etc. 4. Edit .gitignore as necessary 5. git add * 6. git commit -m "commit message" 7. git push So for simple cases you have 3 times as many steps, for more complex cases you have more steps. Note that I usually push/pull from my own github repo and not a central one because that avoids a lot of other hassle (and then use pull requests for managing inter-repo changes, something github has done a nice job with). Additionally absent this you have a significant likelihood that you end up with various files that aren't a part of your build environment (generated makefiles, backups of generated makefiles, built packages, etc) accidently pushed out to your central repo.
    - adekok 13y ago
      Only if you make git that complicated. Steps 2-6 can be replaced with: git commit -m "commit message" file1 file2 ... When you use a tool inefficiently, don't blame the tool.
      - einhverfr 13y ago
        That's still a lot more verbose than svn and even if you do that, you still have only managed to reduce the number of commands required from 3x to 2x what svn requires. Also wouldn't you agree that git has a much steeper learning curve than svn? What is this due to if not the added complexity?
        janvidar 13y ago
        1) Edit some files 2) git commit -a -m "blah blah" 3) git push So, it adds one extra command to push things to an upstream git repository. But, this is the nature of being decentralized.

jmnicolas 13y ago

Before even clicking the SO link, I knew this question was closed as off-topic ... How about they make a dedicated space in SO where this kind of questions are allowed. I don't mean a free for all, but a heavily moderated part where you can ask recommendations from your peers about the best framework / book etc as long as it's related to programming.

viraptor 13y ago
It's been there for ages: http://programmers.stackexchange.com/ http://programmers.stackexchange.com/ Edit: Although it would be great if SO suggested moving discussions there, instead of just closing as off-topic. You can close-move questions that belong to superuser.com for example.
- etler 13y ago
  Why don't they move the question instead of just closing it?
  - viraptor 13y ago
    You've got very limited options when moderating SO unfortunately. When you want to mark the post as belonging to other SE site, the only options are: - meta.stackoverflow.com - superuser.com - tex.stackexchange.com - dba.stackexchange.com - sharepoint.stackexchange.com Which is an... interesting set of choices. I'm not sure why you can't suggest others. I'd really like to migrate to programmers.SE. Otherwise the only option is to actually close as off-topic.
    - ygra 13y ago
      THe list of choices you can vote to move to is based on where questions are migrated most of the time. Moderators can still move the question wherever they want, just flag for attention and give a custom message to that effect.
      - 13y ago

deleted 13y ago

[deleted]

deleted 13y ago

[deleted]

chris_wot 13y ago

Wow, the first answer is so... clueless! Git seems to be the "new, shiny, cool" thing. ... As said above: Git adds complexity. Two modes of creating repositories, checkout vs. clone, commit vs. push... You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository"). ... Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written). Perhaps that is a little harsh. I think the poster just doesn't understand DVCS's.

m_mueller 13y ago
Could you explain what's wrong with that answer? I found it to be spot on, but then again maybe I'm 'clueless' as well.
- chris_wot 13y ago
  The whole point of a DVCS is to be decentralized. Linus Torvalds often just posts his own repository and others pull from it. You can use it as a centralized repo, and it works quite well. In fact, it's how I'm doing development with LibreOffice via gerrit. However, even there I find it easier. I find my workflow is to work on a branch, make sure I have clean commits (I use rebase pretty frequently) and branch and merge often. Frankly, it's easier to work with. I find the staging model to be really excellent, and find it just easier to move up and down commits. But looking at the quotes: Git seems to be the "new, shiny, cool" thing. No, no it's not. Two modes of creating repositories Well, sure. It's literally just a shortcut for setting up groups and then changing a global setting. Repos can go from bare to shared reasonably easily. I fail to see the point. checkout vs. clone Checkout checks out a branch of path to the working directory. Clone gets an entire repository and "clones" it to the current directory. There is no "versus" here, they are two completely different operations. commit vs. push Commit records the changes to the local repository. Push basically takes a ref (a mapping to a sha-1 value that identifies a commit in the tree) and updates a ref in a remote repository. In essence, you are pushing your changes to the remote repository. Again, the thinking of a VCS person, not someone used to DVCSes. You have to know which commands work locally and which work with "the server" Only if you think in terms of centralized repositories. A DVCS is distributed. It's a completely different way of thinking. I find it superior in very many ways. Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. The whole point of git is that you have your version, and you either pull from or push to different repositories and and when needed. The whole idea of centralization is not core to it at all.

flaxin 13y ago

- why is the sky blue? - why do birds sing in the morning? here's why from G-O-D itself: http://www.youtube.com/watch?v=4XpnKHJAok8 http://www.youtube.com/watch?v=4XpnKHJAok8

atmosx 13y ago
I was curious to see if anyone posted this already :-) Awesome talk by my favorite programmer :-P
- deleted 13y ago
  [deleted]

badman_ting 13y ago

Judgment is not the end of the world, and it is not a reflection upon one's character to say that something is better than the tool one currently uses. In other words, it's alright to say that git is better than SVN. If it weren't we wouldn't have all stopped using SVN.

pessimizer 13y ago
>If it weren't we wouldn't have all stopped using SVN. I like git fine, but judging quality by where the crowd is running is like flipping a coin. edit: Fine. We're just going to substitute pith for basic reason here, I guess. Because the industry has largely moved to git, it's clearly the superior tool, and those who don't accept that are clearly emotionally blocked. Or not.
skore 13y ago
In Linus Torvalds' talk on git at google[0], he mentions that the reason why he did not choose SVN (one of the reasons why he saw no other way but to build GIT) was that SVNs mission statement read "To create a compelling replacement for CVS"... which Linus hated with a passion and thus could not see why he would even use "a compelling replacement" of. Interestingly enough, in the 'Open Source projects and poisonous people' talk[1] with two SVN developers, they mention how they chose that line specifically to make sure that everybody is on the same page with the scope of the project - improving upon what people knew and were used to instead of wild, new things. Specifically because they would often have people come into the community with some grand plans that would have just exploded the scope. It is of course arguable to what extent there could be a general rule to this, but in this case, GIT is just so fundamentally and obviously the better option than SVN. Had somebody tried to make SVN into GIT, it would have simply killed SVN, so it was the right course of action to make it a new project. SVN was destined to die by its design. To see the GIT adoption rates these days (particularly due to tools like GitHub) is very encouraging to people who like to think that sometimes, starting over fresh is the only option. Of course, the thing you want to build really has to be that much better than the old thing you're trying to replace. So I agree with you - it's alright to say that GIT is better than SVN. The crucial point to me, though, is that it is so much better. So much better that it is worth the effor to build and worth the effort of the community to switch. [0] https://www.youtube.com/watch?v=4XpnKHJAok8 https://www.youtube.com/watch?v=4XpnKHJAok8 [1] https://www.youtube.com/watch?v=-F-3E8pyjFo https://www.youtube.com/watch?v=-F-3E8pyjFo

wila 13y ago

The question is about two -now old- versions of version control software systems, the question was asked five years ago. Both systems have matured quite a bit making the comments less accurate to actually base an opinion upon.

grexi 13y ago

For all Git users which hate SVN branching - I've added this small shell extension last year: https://github.com/grexi/snippets/tree/master/svnaliases https://github.com/grexi/snippets/tree/master/svnaliases

benihana 13y ago

Why is iOS better than Android? Why is Linux better than OS X? Why is BMW better than Mercedes? Why are Pink Lady apples better than Granny Smith apples? Why is being an omnivore better than being a vegetarian? The way you answer all these questions will be the same. So whether you have an answer or a process to answer these questions, you'll have a pretty good idea about git vs svn.

Goladus 13y ago
The form of the answer may be the same, but not the content. The idea that answers are subject to preference and different needs doesn't mean a question can not have objective answers.

nahname 13y ago

The second answer is pretty good. Benefits: -Works offline -Branches/Merging -Fork another's work -Collaboration -Light weight and fast -Flexible -Tooling (github) Drawbacks of Git: -Hard to learn if you know a centralized SCM.

kyrra 13y ago
Drawback: if you are storing a lot of binary blobs, it will balloon the size of a git repo quickly if those objects change often. While with SVN, users only have to download the latest. To add: there is a reason most game development shops use Perforce. Sometimes you have to deal with large binary assets. Git is just the wrong answer in that case.

GoldenMonkey 13y ago

Choose the right tool for the job. Git is the right tool for: branching and merging. And for cherry picking bug fixes from disparate branches. The git workflow revolves around creating a branch for a feature or bug fix. Because in Git, branching and merging is cheap. I've switched from a decade of using SVN, to Git and it is more than a shiny new tool. It is the right kind of tool for the above. In SVN, branching and merging is expensive, and if the changes between branches were extensive enough.. the merge process would take a good weekend of manual effort. In some scenarios almost impossible to do. And in some shops I worked at, a branch with 3 months of differences would take a week to merge. SVN is not the right tool for this.

T-hawk 13y ago
By contrast, my job is a much better usage case for SVN. We have only three developers, a single trunk, and rolling production deployments. We're never concerned about release or feature branches or back-porting fixes. SVN is the right tool for this. Git's extra abstraction layer around decentralization and distribution would just get in the way. I have used git in a previous job and for personal projects to get something up on Github, and I haven't yet missed it here in our SVN shop. Git is like applying an N log N solution to an algorithmic problem. Great for something that in the naive case would be N² (N branches exchanging updates with each of N branches), but when the problem space is very small, whatever layer represents the log N is just overhead.
- sampo 13y ago
  Nowadays you use Github with SVN, too, if you like.
- FeloniousHam 13y ago
  Even as a single developer, I find the effortless branching in git a killer feature. Even with the poor (from a human perspective) implementation of EGit in Eclipse, the ability to experiment in branches while preserving a "last known good" point would be hard to give up. Add to this the effortless sharing and "cost-less" review provided make git a clear winner.

DougN7 13y ago

Serious question: How/where do you check in your binary builds and debug symbols if you use git? I've read it's not great at some not-so-large project size. I'm using SVN on a micro-sized team with binaries from all released builds safely checked in (which means the repository is probably 100GB-ish in size), and it works great. [and to head off the argument - rebuilding from source is not an option when you have to diagnose a customer crash when they are using a 3 year old build of the software - you'd have to archive a build machine to even have a chance...]

fournm 13y ago
Why are your binary builds living in version control?
- chris_wot 13y ago
  That is the right question!
- DougN7 13y ago
  Why wouldn't they? Conveniently and safely in the same location as the code they were built with. Tagged the same way. Having a separate repository is just inviting trouble down the road, no?
  - fournm 13y ago
    Because they're binary files, used entirely for archival purposes. They shouldn't be changing, they shouldn't have "versions" that are anything to deal with meaningfully as far as your repository is concerned. They should be in flat storage somewhere, with some directory or file name scheme that makes sense based on your version numbers / builds / what have you. Backed up, (ideally) with hashes that verify that they're the same file they once were.