11 ms·

> Anyone else remember the days when having your SVN server go down meant that you more or less had to wait until the server came back up before you could get

> Anyone else remember the days when having your SVN server go down meant that you more or less had to wait until the server came back up before you could get back to doing things? (if you wanted a nice atomic commit). That's now known as "I can't deploy because github is down". Note that the author proposes "local commits plus a centralized storage". > The author mentions that you have to retain the whole history of a project. For one thing, storage is cheap. Not in portable computers. I can get a TB, but that's it. I have build artifacts that clock in at about 300 - 500 MB and I'd version control them if possible. I can't, because that would fill my disk within a couple of month, so I have to push them to a server and somehow link them. > Anyone else ever needed their own fork of something due to differing goals from the parent project, but needed to fold in upstream changes relatively often? That's by nature the sort of problem that a DVCS solves easily. That's a strawman. The article does not argue that there's no use-case that's solved by git or and DVCS. It's just that not every use-case is solved by git. I'd even go out and argue that most use-cases are solved just as good by a solid centralized system with less complexity involved. > Just because we haven't had tools in this space with wide adoption that are user friendly doesn't mean that we won't eventually. I see a developer wedge his git repo with a pull + rebase about once a month. And then somebody needs to walk over and explain. DVCS fundamentally introduce complexity that is not always needed. And I doubt that the fundamental complexity can be abstracted away.

angersock 12y ago
Why are you putting build artifacts into source control?
- Xylakant 12y ago
  Because they're intermediary steps of a process, regenerating them takes an hour and I don't feel like setting up everybody's environment to build them. Most people don't need the capability, but they need the result. Why are you asking?
  - tedunangst 12y ago
    People get pretty religious about what should (or not) be checked in to version control.
    - Xylakant 12y ago
      I can tell from the downvotes :)
    - pyre 12y ago
      It's designed with a particular use-case in mind. When people complain that square pegs don't fit into round holes, it makes more sense for them to step back and evaluate what they are trying to accomplish, and the tools they are using the accomplish it.
  - namdnay 12y ago
    I think the question asked was closer to "why aren't you using an artifact repository?" Nexus is pretty good, but if the language you are using isn't integrated well with gradle/maven you can always just use a shared drive fed by jenkins builds.
    - Xylakant 12y ago
      Valid question: Because the tooling does not think in terms of artifacts that are versioned in repositories, but rather in terms of "files" that are in a given location. I'm using a shared location, but every build requires modifying another file to point to the now current version. It's all solvable, but the easiest solution would be to just version the result. I could fix the tooling, but alas, I have other yaks to shave. It's an imperfect world.
      - pyre 12y ago
        > but every build requires modifying another file to point to the now current version If you could version the file in git, you would have to check in the new version of the file, so it's not like you're adding a step to have to update (e.g.) a symlink.
- deleted 12y ago
  [deleted]
- icefox 12y ago
  What is annoying is when build artifacts are checked into source control systems along side of the source. There is very little way to exclude them or only check out the binaries, you can only have both. This happens all too often and I don't care if you want to keep using subversion you really should stop doing this. /src/foo.c /src/foo.o
- Gorkys 12y ago
  Not the OP, but in our product we have very large binaries that are the output of the product itself. Each time a change is made to the program, the output needs to be compared to the existing output first automatically and if the output isn't byte-by-byte identical then manually (visually). So essentially, without large binaries in source control we'd lose testing.
iand675 12y ago
> Not in portable computers. I can get a TB, but that's it. I have build artifacts that clock in at about 300 - 500 MB and I'd version control them if possible. I can't, because that would fill my disk within a couple of month, so I have to push them to a server and somehow link them. git-annex is a pretty good solution for this: https://git-annex.branchable.com/ https://git-annex.branchable.com/ > That's a strawman. The article does not argue that there's no use-case that's solved by git or and DVCS. It's just that not every use-case is solved by git. I'd even go out and argue that most use-cases are solved just as good by a solid centralized system with less complexity involved. I'm not convinced that it is a strawman– I'm not an uber-developer, but I've had to do it reasonably often. A common case is that the originator loses interest, and you still need to do maintenance on it. I'd rather my go-to choice of a version control system support that notion rather than learn a different tool to deal with this case. > I see a developer wedge his git repo with a pull + rebase about once a month. And then somebody needs to walk over and explain. DVCS fundamentally introduce complexity that is not always needed. And I doubt that the fundamental complexity can be abstracted away. Sure, there is an additional level of abstraction, but to argue that it's insurmountable seems rather pessimistic. Most technologies that we take for granted now required multiple decades to get to a consumer-friendly state. This is perhaps a philosophical difference that only time will answer.
- namdnay 12y ago
  I'm not a fan of solutions like git-annex, every time I've seen people try to do this type of stuff, two years down the line they end up having built a buggy knockoff of maven/gradle. Why not do things cleanly from the start? The entry barrier is really not that high, and the benefits are huge. Then again maybe I'm a bit psycho-rigid on build management :)
  - stsp 12y ago
    You're absolute right from my experience. I"ve seen many shops using svn:externals to tie build dependencies together. And now that git is starting to see wider adoption within industry (not just software companies) the same is attempted with git submodules and git annex. It's horrible because this is not the use case these features were designed for, but people try anyway and eventually run into road blocks. This tends to happen especially in shops that migrate off process-heavy monsters like clearcase and MKS. These tools do a lot more than just version control, and no open source version control system by itself matches what users of these systems expect. You have to throw at least an issue tracker and a good build tool into the mix as well.
jimktrains2 12y ago
> That's now known as "I can't deploy because github is down". Note that the author proposes "local commits plus a centralized storage". And in that cause you can scp your repo somewhere and change your origin and move on. Also, do people really rely on 3rd party services for their deployed code? I've used github as a repo and colab tool at companies, but we still deployed from repos owned by the company. > I'd even go out and argue that most use-cases are solved just as good by a solid centralized system with less complexity involved. I'd go out an argue that because the added complexity of git is far outweighed by the benefits of a local repo.
- teej 12y ago
  Also, do people really rely on 3rd party services for their deployed code? Yes, this is very common.
  - gfodor 12y ago
    Also the fact that each developer has a full copy of the repo on their laptop lets me sleep at night wrt github exploding.
    - TeMPOraL 12y ago
      Or your company exploding or pretty much anything exploding. When every dev has a full copy of the repo, you can restore all the work as long as a single dev machine is alive. Not to mention that in case of an office Internet outage, you can just mesh together those repos and continue working. Knowing that gives me some peace of mind.
    - Xylakant 12y ago
      It also means that you get to loose control over all data in the repo including all versions and history when a single person looses the laptop, even if it's a person that only required read access to a tiny part of the data. It's a valid tradeoff to make, but still something I'd keep in mind.
      - 12y ago
kbenson 12y ago
That's now known as "I can't deploy because github is down". git != github. I use git every day at work. I don't use github for that repo. If I did, I wouldn't make reliance on it part of my deployment strategy. If I did do so, I hope I would realize that any problems relying on github resulted in were ones I created with that choice. Hopefully there would be some useful benefits from that choice as well.
mikeash 12y ago
How do you get local commits plus a centralized storage without basically building a DVCS?
- Xylakant 12y ago
  Local commits do not require the full history, only a known base. So you could in essence store the commits relative To the last pull from the server and push those later. No need for full history.
  - erikb 12y ago
    I have to agree here. You only need a startpoint. In essence a commit is a diff on that startpoint. So "cloning" a single commit should be enough to create a new one and push it.
    - falsedan 12y ago
      git has 'shallow' clones, where it checks out the tree as it was at a particular commit, and has a dummy commit which replaces the history of the repo up until that particular commit.
  - lmm 12y ago
    You could indeed do that. But now you have two different kinds of commit that can conflict in surprising ways. I very much doubt you could manage this in a way that's simpler than what git does (remote branches and local branches are branches, you can merge one into the other using the normal tooling you use for merging branches).
    - Xylakant 12y ago
      I'm fairly sure that at least on the ui-side you could improve over git, but the goal is not necessarily lower complexity. A semi-distributed system could have other advantages, for example fine-grained access control (read permissions on folder or file-level), support for partial checkouts, better support for large binaries (only the last revision on the local repo, older revisions on the server) etc. git currently can't do that because of the way it's designed and built.
deeviant 12y ago
> Not in portable computers. I can get a TB, but that's it. I have build artifacts that clock in at about 300 - 500 MB and I'd version control them if possible. I can't, because that would fill my disk within a couple of month, so I have to push them to a server and somehow link them. Why in the world would you check in build artifacts into source control, especially those that clock in at 300-500 MB?
- Crito 12y ago
  Because you are accustomed to centralized version control systems that do not punish you for doing something that dumb, and refuse to learn new tools when you are forced to use them. Anyone checking in 500MB artifacts into git is almost certainly refusing to use git correctly. It is like somebody who grows up using hand tools, gets handed a power drill, then tries to use it like a pry-bar. You should not use a screwdriver as a pry-bar, that is an abuse of the tool. Nevertheless, many people abuse screwdrivers as pry-bars because conventional hand screwdrivers tolerate this practice.
  - Xylakant 12y ago
    Thanks for assuming I'm an idiot without knowing the constraint I'm trying to fulfill ;)
    - Crito 12y ago
      > "almost certainly" You might have a legitimate reason for putting 500MB artifacts into a git repo, but I reeeaaally doubt it. It is a poor craftsman who blames tools that he is intent on misusing.
      - Xylakant 12y ago
        You're putting words in my mouth that I did never say. I'm not blaming git for anything nor do I consider git a bad tool. I'm using git for practically all my versioned data. I just don't consider it the tool that needs to solve all cases where I - legitimately or not - want to version data. A good craftsman should have more tools at his disposal than just a blunt hammer. So you can doubt my use case but I consider it severely impolite to pretend that you know better. Actually you're quite nicely illustrating one of the points in the article.
s_q_b 12y ago
The main reason for the abandonment of centralized version control was as much about Git and Mercurial having the advantages of DVCSes as it was about SVN starting to show its age. I found SVN literally painful to use, perhaps because it was based around CVS's standards, and CVS was originally a series of shell scripts written in 1990.
eridius 12y ago
> I see a developer wedge his git repo with a pull + rebase about once a month. And then somebody needs to walk over and explain. DVCS fundamentally introduce complexity that is not always needed. Rebase and DVCS are orthogonal concepts. Rebase is a consequence of offline commits, not of decentralization. And I greatly prefer dealing with a `git rebase` issue than the equivalent in Subversion, which is to have your uncommitted local changes get irrevocably modified by the `svn update`, with conflict markers placed in your code and no way to abort the whole process.
- pyre 12y ago
  But... but... but... git bad!
  - eridius 12y ago
    It's a prevalent meme, isn't it? I'm surprised at how many people never even realized how fundamentally dangerous it was to issue an `svn update` with local changes. And perhaps less seriously but still problematic, how `svn commit` can put the repository into a state that never existed on any developer's machine (because it effectively does a rebase on the server), which is not always safe to do even when there's no merge conflicts.
    - Xylakant 12y ago
      > how `svn commit` can put the repository into a state that never existed on any developer's machine git add -p creates the same issue for git (a commit that never existed on disk) and git rebase with squash and/or reodering of commits does as well. That's usually considered best practice. The problem I often observe with git (pull -)rebase is that people have a hard time wrapping their mind around the fact that all commits change and when they change and in what state the checkout is are when they get a merge conflict (remote HEAD plus whatever was already applied). The conflict is often unavoidable and you can argue that rebase is making it easier to resolve the conflict, but it's harder to reason about than "ok, update does a merge and I get whatever is on the server plus my local changes".
erikb 12y ago
I think you argue in the same direction I often argue. Git is not for everybody. If you don't want to spend the time to learn git you probably are better of using something else. Additionally I would like to add something: There are more cases were you need than you think, especially if you haven't learned it. E.g., you start a little prototype to present to your boss. It succeeds, boom, ten years later you have 100 man team working on the same prototype you started 10 years ago. Suddenly you really need forks, branches, some people spend their whole day merging stuff, etc. But hey, you can't switch from SVN because you have chosen it in the beginning and now everybody is using it, all kinds of scripts, tools, and optimized workflows require that you continue to use it. Some people might think that spending two weeks in the beginning to learn to use a power tool is much better than starting earlier and thereby getting years of pain later on.
- semi-extrinsic 12y ago
  I agree: whenever you find yourself saying "I don't have time to learn this advanced tool that will make my life better, I have to ship now!", you should really take a moment and carefully verify that this is a good choice. (Sometimes it is a good choice though.) In the world of science, I have colleagues who have said this for ten years wrt. LaTeX vs. Word, or even just learning EndNote vs. typing up reference lists by hand. I cringe every time I watch them spend an order of magnitude more time on pure overhead, and always getting stuff wrong, for every single paper they put out.
  - erikb 12y ago
    That's a really good reason: When you are unable to learn it correctly (maybe simply because it's too complicated). With the simple tool you are still not able to do all the cool stuff, but at least you can get something simple done fast.
pyre 12y ago
> That's now known as "I can't deploy because github is down". No. No it's not. "I can't deploy" is different than "I can't work," unless you "move fast and break things" by deploying as soon as you push your code. Even then git allow you to continue to work, even if you haven't deployed your code.
lmm 12y ago
> That's now known as "I can't deploy because github is down". I had that happen a few months ago. Had to push the repo to bitbucket and change where a config file pointed to. It took almost as long as doing a merge in SVN. > I have build artifacts that clock in at about 300 - 500 MB and I'd version control them if possible. I can't, because that would fill my disk within a couple of month, so I have to push them to a server and somehow link them. Those are very unlike source code. You're not going to want or be able to diff them, or blame them, or view their history. A different tool is appropriate. > I see a developer wedge his git repo with a pull + rebase about once a month. And then somebody needs to walk over and explain. Yeah. I see that at about the same rate I saw developers lose data back in the svn days. Git can "wedge itself" but never in a way that induces data loss, IME, in stark contrast to its predecessors.
- pyre 12y ago
  > view their history You can view the history of binary blobs in a git repo.
HelloNurse 12y ago
"I see a developer wedge his git repo with a pull + rebase about once a month. And then somebody needs to walk over and explain." Accidents happen, but the pattern of making people make highly predictable mistakes and then calling in the experts is the result of not investing on basic training (and possibly not hiring smart enough people, but it's another matter). By the way, that "wedged" repository in all likelihood has an uncorrupted working copy containing all changes and can be repaired offline: Git is technically so superior to Subversion and TFS that it isn't even fun.

angersock 12y ago

Why are you putting build artifacts into source control?

Xylakant 12y ago
Because they're intermediary steps of a process, regenerating them takes an hour and I don't feel like setting up everybody's environment to build them. Most people don't need the capability, but they need the result. Why are you asking?
- tedunangst 12y ago
  People get pretty religious about what should (or not) be checked in to version control.
  - Xylakant 12y ago
    I can tell from the downvotes :)
  - pyre 12y ago
    It's designed with a particular use-case in mind. When people complain that square pegs don't fit into round holes, it makes more sense for them to step back and evaluate what they are trying to accomplish, and the tools they are using the accomplish it.
- namdnay 12y ago
  I think the question asked was closer to "why aren't you using an artifact repository?" Nexus is pretty good, but if the language you are using isn't integrated well with gradle/maven you can always just use a shared drive fed by jenkins builds.
  - Xylakant 12y ago
    Valid question: Because the tooling does not think in terms of artifacts that are versioned in repositories, but rather in terms of "files" that are in a given location. I'm using a shared location, but every build requires modifying another file to point to the now current version. It's all solvable, but the easiest solution would be to just version the result. I could fix the tooling, but alas, I have other yaks to shave. It's an imperfect world.
    - pyre 12y ago
      > but every build requires modifying another file to point to the now current version If you could version the file in git, you would have to check in the new version of the file, so it's not like you're adding a step to have to update (e.g.) a symlink.
deleted 12y ago
[deleted]
icefox 12y ago
What is annoying is when build artifacts are checked into source control systems along side of the source. There is very little way to exclude them or only check out the binaries, you can only have both. This happens all too often and I don't care if you want to keep using subversion you really should stop doing this. /src/foo.c /src/foo.o
Gorkys 12y ago
Not the OP, but in our product we have very large binaries that are the output of the product itself. Each time a change is made to the program, the output needs to be compared to the existing output first automatically and if the output isn't byte-by-byte identical then manually (visually). So essentially, without large binaries in source control we'd lose testing.

iand675 12y ago

> Not in portable computers. I can get a TB, but that's it. I have build artifacts that clock in at about 300 - 500 MB and I'd version control them if possible. I can't, because that would fill my disk within a couple of month, so I have to push them to a server and somehow link them. git-annex is a pretty good solution for this: https://git-annex.branchable.com/ https://git-annex.branchable.com/ > That's a strawman. The article does not argue that there's no use-case that's solved by git or and DVCS. It's just that not every use-case is solved by git. I'd even go out and argue that most use-cases are solved just as good by a solid centralized system with less complexity involved. I'm not convinced that it is a strawman– I'm not an uber-developer, but I've had to do it reasonably often. A common case is that the originator loses interest, and you still need to do maintenance on it. I'd rather my go-to choice of a version control system support that notion rather than learn a different tool to deal with this case. > I see a developer wedge his git repo with a pull + rebase about once a month. And then somebody needs to walk over and explain. DVCS fundamentally introduce complexity that is not always needed. And I doubt that the fundamental complexity can be abstracted away. Sure, there is an additional level of abstraction, but to argue that it's insurmountable seems rather pessimistic. Most technologies that we take for granted now required multiple decades to get to a consumer-friendly state. This is perhaps a philosophical difference that only time will answer.

namdnay 12y ago
I'm not a fan of solutions like git-annex, every time I've seen people try to do this type of stuff, two years down the line they end up having built a buggy knockoff of maven/gradle. Why not do things cleanly from the start? The entry barrier is really not that high, and the benefits are huge. Then again maybe I'm a bit psycho-rigid on build management :)
- stsp 12y ago
  You're absolute right from my experience. I"ve seen many shops using svn:externals to tie build dependencies together. And now that git is starting to see wider adoption within industry (not just software companies) the same is attempted with git submodules and git annex. It's horrible because this is not the use case these features were designed for, but people try anyway and eventually run into road blocks. This tends to happen especially in shops that migrate off process-heavy monsters like clearcase and MKS. These tools do a lot more than just version control, and no open source version control system by itself matches what users of these systems expect. You have to throw at least an issue tracker and a good build tool into the mix as well.

jimktrains2 12y ago

> That's now known as "I can't deploy because github is down". Note that the author proposes "local commits plus a centralized storage". And in that cause you can scp your repo somewhere and change your origin and move on. Also, do people really rely on 3rd party services for their deployed code? I've used github as a repo and colab tool at companies, but we still deployed from repos owned by the company. > I'd even go out and argue that most use-cases are solved just as good by a solid centralized system with less complexity involved. I'd go out an argue that because the added complexity of git is far outweighed by the benefits of a local repo.

teej 12y ago
Also, do people really rely on 3rd party services for their deployed code? Yes, this is very common.
- gfodor 12y ago
  Also the fact that each developer has a full copy of the repo on their laptop lets me sleep at night wrt github exploding.
  - TeMPOraL 12y ago
    Or your company exploding or pretty much anything exploding. When every dev has a full copy of the repo, you can restore all the work as long as a single dev machine is alive. Not to mention that in case of an office Internet outage, you can just mesh together those repos and continue working. Knowing that gives me some peace of mind.
  - Xylakant 12y ago
    It also means that you get to loose control over all data in the repo including all versions and history when a single person looses the laptop, even if it's a person that only required read access to a tiny part of the data. It's a valid tradeoff to make, but still something I'd keep in mind.
    - 12y ago

kbenson 12y ago

That's now known as "I can't deploy because github is down". git != github. I use git every day at work. I don't use github for that repo. If I did, I wouldn't make reliance on it part of my deployment strategy. If I did do so, I hope I would realize that any problems relying on github resulted in were ones I created with that choice. Hopefully there would be some useful benefits from that choice as well.

mikeash 12y ago

How do you get local commits plus a centralized storage without basically building a DVCS?

Xylakant 12y ago
Local commits do not require the full history, only a known base. So you could in essence store the commits relative To the last pull from the server and push those later. No need for full history.
- erikb 12y ago
  I have to agree here. You only need a startpoint. In essence a commit is a diff on that startpoint. So "cloning" a single commit should be enough to create a new one and push it.
  - falsedan 12y ago
    git has 'shallow' clones, where it checks out the tree as it was at a particular commit, and has a dummy commit which replaces the history of the repo up until that particular commit.
- lmm 12y ago
  You could indeed do that. But now you have two different kinds of commit that can conflict in surprising ways. I very much doubt you could manage this in a way that's simpler than what git does (remote branches and local branches are branches, you can merge one into the other using the normal tooling you use for merging branches).
  - Xylakant 12y ago
    I'm fairly sure that at least on the ui-side you could improve over git, but the goal is not necessarily lower complexity. A semi-distributed system could have other advantages, for example fine-grained access control (read permissions on folder or file-level), support for partial checkouts, better support for large binaries (only the last revision on the local repo, older revisions on the server) etc. git currently can't do that because of the way it's designed and built.

deeviant 12y ago

Crito 12y ago
Because you are accustomed to centralized version control systems that do not punish you for doing something that dumb, and refuse to learn new tools when you are forced to use them. Anyone checking in 500MB artifacts into git is almost certainly refusing to use git correctly. It is like somebody who grows up using hand tools, gets handed a power drill, then tries to use it like a pry-bar. You should not use a screwdriver as a pry-bar, that is an abuse of the tool. Nevertheless, many people abuse screwdrivers as pry-bars because conventional hand screwdrivers tolerate this practice.
- Xylakant 12y ago
  Thanks for assuming I'm an idiot without knowing the constraint I'm trying to fulfill ;)
  - Crito 12y ago
    > "almost certainly" You might have a legitimate reason for putting 500MB artifacts into a git repo, but I reeeaaally doubt it. It is a poor craftsman who blames tools that he is intent on misusing.
    - Xylakant 12y ago
      You're putting words in my mouth that I did never say. I'm not blaming git for anything nor do I consider git a bad tool. I'm using git for practically all my versioned data. I just don't consider it the tool that needs to solve all cases where I - legitimately or not - want to version data. A good craftsman should have more tools at his disposal than just a blunt hammer. So you can doubt my use case but I consider it severely impolite to pretend that you know better. Actually you're quite nicely illustrating one of the points in the article.

s_q_b 12y ago

The main reason for the abandonment of centralized version control was as much about Git and Mercurial having the advantages of DVCSes as it was about SVN starting to show its age. I found SVN literally painful to use, perhaps because it was based around CVS's standards, and CVS was originally a series of shell scripts written in 1990.

eridius 12y ago

> I see a developer wedge his git repo with a pull + rebase about once a month. And then somebody needs to walk over and explain. DVCS fundamentally introduce complexity that is not always needed. Rebase and DVCS are orthogonal concepts. Rebase is a consequence of offline commits, not of decentralization. And I greatly prefer dealing with a `git rebase` issue than the equivalent in Subversion, which is to have your uncommitted local changes get irrevocably modified by the `svn update`, with conflict markers placed in your code and no way to abort the whole process.

pyre 12y ago
But... but... but... git bad!
- eridius 12y ago
  It's a prevalent meme, isn't it? I'm surprised at how many people never even realized how fundamentally dangerous it was to issue an `svn update` with local changes. And perhaps less seriously but still problematic, how `svn commit` can put the repository into a state that never existed on any developer's machine (because it effectively does a rebase on the server), which is not always safe to do even when there's no merge conflicts.
  - Xylakant 12y ago
    > how `svn commit` can put the repository into a state that never existed on any developer's machine git add -p creates the same issue for git (a commit that never existed on disk) and git rebase with squash and/or reodering of commits does as well. That's usually considered best practice. The problem I often observe with git (pull -)rebase is that people have a hard time wrapping their mind around the fact that all commits change and when they change and in what state the checkout is are when they get a merge conflict (remote HEAD plus whatever was already applied). The conflict is often unavoidable and you can argue that rebase is making it easier to resolve the conflict, but it's harder to reason about than "ok, update does a merge and I get whatever is on the server plus my local changes".

erikb 12y ago

I think you argue in the same direction I often argue. Git is not for everybody. If you don't want to spend the time to learn git you probably are better of using something else. Additionally I would like to add something: There are more cases were you need than you think, especially if you haven't learned it. E.g., you start a little prototype to present to your boss. It succeeds, boom, ten years later you have 100 man team working on the same prototype you started 10 years ago. Suddenly you really need forks, branches, some people spend their whole day merging stuff, etc. But hey, you can't switch from SVN because you have chosen it in the beginning and now everybody is using it, all kinds of scripts, tools, and optimized workflows require that you continue to use it. Some people might think that spending two weeks in the beginning to learn to use a power tool is much better than starting earlier and thereby getting years of pain later on.

semi-extrinsic 12y ago
I agree: whenever you find yourself saying "I don't have time to learn this advanced tool that will make my life better, I have to ship now!", you should really take a moment and carefully verify that this is a good choice. (Sometimes it is a good choice though.) In the world of science, I have colleagues who have said this for ten years wrt. LaTeX vs. Word, or even just learning EndNote vs. typing up reference lists by hand. I cringe every time I watch them spend an order of magnitude more time on pure overhead, and always getting stuff wrong, for every single paper they put out.
- erikb 12y ago
  That's a really good reason: When you are unable to learn it correctly (maybe simply because it's too complicated). With the simple tool you are still not able to do all the cool stuff, but at least you can get something simple done fast.

pyre 12y ago

> That's now known as "I can't deploy because github is down". No. No it's not. "I can't deploy" is different than "I can't work," unless you "move fast and break things" by deploying as soon as you push your code. Even then git allow you to continue to work, even if you haven't deployed your code.

lmm 12y ago

> That's now known as "I can't deploy because github is down". I had that happen a few months ago. Had to push the repo to bitbucket and change where a config file pointed to. It took almost as long as doing a merge in SVN. > I have build artifacts that clock in at about 300 - 500 MB and I'd version control them if possible. I can't, because that would fill my disk within a couple of month, so I have to push them to a server and somehow link them. Those are very unlike source code. You're not going to want or be able to diff them, or blame them, or view their history. A different tool is appropriate. > I see a developer wedge his git repo with a pull + rebase about once a month. And then somebody needs to walk over and explain. Yeah. I see that at about the same rate I saw developers lose data back in the svn days. Git can "wedge itself" but never in a way that induces data loss, IME, in stark contrast to its predecessors.

pyre 12y ago
> view their history You can view the history of binary blobs in a git repo.

HelloNurse 12y ago

"I see a developer wedge his git repo with a pull + rebase about once a month. And then somebody needs to walk over and explain." Accidents happen, but the pattern of making people make highly predictable mistakes and then calling in the experts is the result of not investing on basic training (and possibly not hiring smart enough people, but it's another matter). By the way, that "wedged" repository in all likelihood has an uncorrupted working copy containing all changes and can be repaired offline: Git is technically so superior to Subversion and TFS that it isn't even fun.