8 ms·

Distributed Version Control is here to stay, baby

235 points by mattyb 17y ago

jackfoxy 17y ago
I've only lived through one version control migration, that was from TFS to Subversion. The problem we have is the length of time Subversion takes doing updates, commits, and merges when you are dealing with a large repository and many changes spread out among files. (Good old TFS was fast.) Can anyone say if Mercurial is significantly faster? After going through Joel's tutorial it looks like Mercurial keeps history from branches in the root much better than either TFS or Subversion. I think I would opt for Mercurial the next time I have to set up source control.
- j_baker 17y ago
  Try out git. Force yourself to use it for a few weeks. I didn't like it at first. I used to be a Mercurial guy until I really learned git. I still don't know what it is, but there's something about git that just makes me want to love it.
- kneath 17y ago
  I can say without hesitation mercurial or git will be insanely faster for these operations. Remember, you work locally, and then push with hg/git. So when you do "git commit" it only relies on the speed of your hard drive/cpu. Commits happen instantly. Updates are needed very rarely (since you don't need to update to make new commits). Merges are so much faster it's not even funny. After merging in hg/git you wonder why SVN even had a merge functionality. In addition to those conceptual differences, the actual act of transferring files between remote and local on git/hg is also much faster than SVN. Entire checkouts of git repositories are usually smaller (disk size) than the equivalent SVN checkout... of one version. This means less time on the network all around.
  - jackfoxy 17y ago
    Yeah, committing to your local copy better be fast, it's committing to the shared server repository that I'm concerned about.
    - chousuke 17y ago
      I think you'll find that whatever git does, it's faster than the corresponding operation in SVN. When you send commits to a remote server, git compresses them and sends the packfile over the network. The server will refuse non-fast forward merges (the branch you're pushing is supposed to be merged by you first, locally) so it pretty much has nothing to do but uncompress the changes and apply them. Unless you have a really slow network or are sending an insane number of commits, it's not going to take longer than a few seconds. Cloning big repositories (like emacs, with ~25 years of history) can take a while if you have a slow network, but sometimes it feels like git can actually clone a repository faster than SVN can check out a single revision. But repos like emacs' are rare. Often, SVN repositories end up being huge because they contain the code of many unrelated projects. In Git, having such a huge repository is impractical; each project should have its own repository. There is support for submodules though, so you can make a "master" repo that contains pointers to the child repositories, if you really have to.
revorad 17y ago
Blogging is hard to give up, Joel? Edit: Uh stop upvoting me please. That was a tongue-in-cheek comment and, as sant0sk1 pointed out below, also lazy on my part.
- giu 17y ago
  I think it's the last one. Tweeted 5 minutes ago by Joel (http://twitter.com/spolsky/status/10671213571 http://twitter.com/spolsky/status/10671213571): "The last Joel on Software article[...]"
- spolsky 17y ago
  Not at all! Today is the ten-year anniversary of my first real post, so I've been planning to have my last real post on 3/18 for a long time. Thanks for all your attention over the years. I'll still be around, just not doing these essays any more.
  - revorad 17y ago
    Cool. I'm sure many will enjoy your archives for years to come.
  - dugmartin 17y ago
    Thanks for all the work over the years. The silent majority is grateful.
  - jswinghammer 17y ago
    Thank you for what you've been doing over the last ten years. I'm not sure what my career would look like without Joel on Software. It really helped shape my outlook and encouraged me to invest in reading and learning more about programming than I would have otherwise. I wish you nothing but the best with your new venture and with Fog Creek.
  - Sukotto 17y ago
    Don't you think you'd be better off posting that "I've run the clock out" paragraph as it's own thing? It seems important enough to be it's own post. Thank you for all your articles. I've learned a lot from them over the years and consider them really first class. Hell, my printout of the Joel Test is one of the three things taped to my desk (The other two being Merlin Mann's 5 Inbox-zero words and "Your Company's App" by Eric Burke)
graywh 17y ago
"If you are using Subversion, stop it. Just stop. Subversion = Leeches. Mercurial and Git = Antibiotics." This is great. A few years ago, DVCS was weird and strange and SVN was the stuff. When people discover how awesome Git and Mercurial are, they stab SVN/CVS in the back.
- axod 17y ago
  Such is the life of hipsters.
- kylemathews 17y ago
  "stab SVN/CVS in the back"??? I'm not sure why you're borrowing an assassination metaphor to describe someone's shift in technology choices. Technology aren't people.
  - graywh 17y ago
    Would you rather I'd said "throw X under the bus"?
    - pingswept 17y ago
      No one has to be executed here. How about "start using a different tool"?
- Sukotto 17y ago
  That's just life in technology as the tools improve. 1) Stop manually backing up versions, that's error-prone. Use RCS! 2) Stop using RCS, it doesn't scale. Use CVS! 3) Stop using CVS, it's too complicated. Use SVN! 4) Stop using SVN, it makes it hard to merge branches. Use Hg/GIT! ... And someday, we'll be saying 5) Stop using Hg/GIT. They ________. Use _______! Same thing for hardware, and languages, and frameworks... and just about everything. shrug
  - axod 17y ago
    It's funny how it's usually easier to ditch X, and write Y from scratch, rather than try to improve X.
bruceboughton 17y ago
But how does thinking about changes rather than versions make things easier, Joel? You never quite explain...
- axod 17y ago
  A version is just a changeset, so for me, it makes little sense to claim "changes" are a completely different way of thinking than "versions". Perhaps it comes down to how you divide work up. I just don't like branches. They're mess.
  - nuclear_eclipse 17y ago
    I think the biggest conceptual difference between looking at "versions" versus "changes" is that versions imply a linear, static, and/or sequential history of revisions. By instead thinking of changes, you get a more open concept of a malleable history, in which you have more freedom to change histories or branches. Eg, if you want to split the development branch (trunk?) into two competing experiments, and then discard the losing branch at the end, a linear history of version/revision numbers split between two branches seems limiting IMO. Eg2, if you are working on a new feature or set of code that you haven't yet pushed to the server, having an open stack of changes gives you the freedom to modify and improve those changes without cluttering the commit history. When you're done, you simply push the finalized set of changes on top of the target branch.
    - axod 17y ago
      For me though, the linear element of versions helps me since it mirrors how I work - linearly with a constantly increasing value of time.
      - aidenn0 17y ago
        So you never branch or merge?
        17y ago
steilpass 17y ago
"we developed a new way of developing software using if statements instead of branches." Is that critizing feature flags? Or is more to that?
- axod 17y ago
  It often makes sense to have 2 alternate implementations of a component in the same codebase, so you can switch between them at startup/during runtime, and compare them side by side. Something that isn't as easy to do if you create 2 separate branches.
  - etherealG 17y ago
    I think a better solution is to have both features in branches, and have a 3rd branch which allows realtime switching between the 2. a nice upside is that you can merge changes to each feature up into the "combined" branch as they get stable, to test side by side. when you finally finish, you can leave feature a behind by merging b into your release, or vice versa. or maybe even merge both into mainline. sorry, the point I was trying to make is that cheap branching and merging is still an easier way to manage this situation than just ignoring branches altogether.
    - axod 17y ago
      In what way easier? A: Create separate branches, manage merging/updating unrelated changesets. B: Create 2 implementations of something in code, and manage nothing. I guess it depends on how easy it is to isolate the part you want to create 2 implementations of, so it may depend on what language you're using as well as how you architected things. Branching+Merging just seems like something extra I have to do, manage, and remember. Like filing. And I still can't see what benefit it gives for many cases. But that's fine I think... I just don't get it. Maybe I'm too old ;)
  - barrkel 17y ago
    Well, if you have a well defined protocol / interface for your component, and you have a runtime versioning mechanism (something as simple differently named DLLs will do if you're at the C level), then you ought to be able to do both: put the new code in a separate branch, but still switch in the old code at runtime. An advantage of keeping an old code in its own branch is that it's less likely to become incompatible through random changes. In particular, I'm thinking of bug compatibility: there may be bugs you wish to fix in the new code, but you don't want to fix in the older code because of third-party dependencies.
omergertel 17y ago
It helped me to think about it in terms of connected graphs. Nodes are versions and arcs are changes. A path between two versions is the aggregation of changes. Merging then becomes walking down the same path, but starting from a different node. I start at my current version node, and I walk down your path of changes. It's very different than trying to merge two nodes. (This is just my mental model, no need to read into it more than that)
Aegean 17y ago
How this article got so much points I'll never know. Its some novice advice on version control. Why don't you read the git books, they'll tell you all about it in well-organized fashion: http://book.git-scm.com http://book.git-scm.com
- SriniK 17y ago
  yup.. seriously why so many points? common editors/superusers...
- Aegean 17y ago
  Agree: Upvote, Disagree: Downvote. That shouldn't be the way to go. I insist the article is novice advice. At least take the time to reply on how you find it original rather than simply downvote.
smokinn 17y ago
What an excellent way to go out. Great last article Joel.
praptak 17y ago
"The interesting part is that these systems think in terms of changes, not in terms of versions." Not git. Git's repository model is very strongly snapshot-oriented. Of course the whole machinery for supporting changesets exists in git, but it is built atop a system that actively avoids "thinking" in terms of changes. Linus on this: http://marc.info/?l=linux-kernel&m=111314792424707 http://marc.info/?l=linux-kernel&m=111314792424707
- schacon 17y ago
  The storage model does not - it is not file-delta based, like SVN and Mercurial. However, you as a developer can (and often do) think of the commits in terms of a changeset or "work introduced" - this is evident in tools that exist like 'rebase' which treats each commit in a branch as a patch and the collection of unique commits on that branch as a patch series and helps you transfer that series elsewhere. The 'cherry-pick' command is similar - it enforces your thinking of each commit as a changeset or patch to what came before it.
- weavejester 17y ago
  I don't think that link contradicts Joel. Git represents repositories as a network of diffs, not a linear history of versions.
  - praptak 17y ago
    This is not true for git's object model (which I believe maps to Joel's "user model".) Quote The Git Book: "Subversion, CVS, Perforce, Mercurial and the like all use Delta Storage systems - they store the differences between one commit and the next. Git does not do this - it stores a snapshot of what all the files in your project look like in this tree structure each time you commit. This is a very important concept to understand when using Git." Source:http://book.git-scm.com/1_the_git_object_model.html http://book.git-scm.com/1_the_git_object_model.html However the diffs are there below the snapshot-based model as means of effectively storing and transmitting the snapshots.
    - nas 17y ago
ableal 17y ago
There's something bothering me about the hosannas to the power of merging changes. Isn't there an unspoken assumption that all your work is text files ? If we talk drawings, photos, whatever binary data is needed for a project - what happens ? Are the binary deltas as good as SVN's ? Even if the "binaries" are XML text - e.g. drawings in SVG - wouldn't I be out of luck trying to merge changes if 'Beth' added a squiggle and 'Cath' a square to different parts of the drawing ? (many tools, upon writing, reorder data 'ad lib'). Are there "merge tool" plug-ins ?
- schacon 17y ago
  Binaries are not merged - if histories diverge and one side changes but the other does not, it will choose the side that changes. If both sides change, it will record a conflict and you have to choose one side (or create a new binary that you tell the system is resolved). You can run an external merge tool with 'git mergetool' and there are over a dozen it knows how to run, but I don't know which of them will handle images. You can also use .gitattributes to help you diff binary files efficiently, but you still have to either choose one side or manually create a new binary. I mean, even a merge tool won't help much there - if you have images that changed on two different branches and you want to combine them, you have to fire up Photoshop or something anyways - that's almost always going to be a manual process. Though, in the four or so years I've been using Git (and the years before that with SVN and CVS and RCS) I don't remember having to do that very often - thus is the life of a coder, I suppose. The people who create and modify images for programs tend not to tread on each other. Also, this is really the same problem even for systems without solid branching capability, like SVN. If two people modify a binary image at the same time and one commits, then the other will get a merge conflict when they update and will have to solve the conflict in order to commit.
10ren 17y ago
It's a DAG. The arcs are diffs (edits).
fnid2 17y ago
So is Joel's blog apparently.
- gruseom 17y ago
  He implies in the last paragraph that it's his final post. Still, I think there's a point here. Writing, when you're that good at it, isn't so easy to give up. Also, the blog has been a huge part of Spolsky's success. So I bet he'll revive or continue it in some form before too long. Edit: I hope he does, too. I probably disagree with him more than half the time, but there are few other writers on software who consistently hold my attention, and almost no one who consistently makes me laugh.
  - Periodic 17y ago
    I would be happy to seem him move to a more personal blog. Something that is a little more about his personal experiences with technology. It sounded like he didn't like the regularly-published business-oriented posts. I wouldn't mind a picture of Taco on each post.
swolchok 17y ago
That backpack anecdote is a play straight out of Guy Kawasaki's The Macintosh Way (http://www.amazon.com/MacIntosh-Way-Guy-Kawasaki/dp/0060973382/ref=sr_1_1?ie=UTF8&s=books&qid=1268951347&sr=8-1 http://www.amazon.com/MacIntosh-Way-Guy-Kawasaki/dp/00609733...), which is on Joel's recommended reading list for managers (http://www.joelonsoftware.com/articles/FogCreekMBACurriculum.html http://www.joelonsoftware.com/articles/FogCreekMBACurriculum...).
po 17y ago
What's wrong with a jalapeño bagel?
abalashov 17y ago
For me, it always has been and always will be a right tool for the job issue. We work on relatively small code bases with a very small team of people, not large, unwieldy open-source projects with hundreds of contributors. Primary interest is in a log of what has happened to the code chronologically, rather than applying/unapplying specific revisions/hunks frequently. No need whatsoever for people to run with their own branches. With those requirements, git, Hg or Darcs would all present far, far more headache than they're worth versus Subversion. In some other scenarios, the formula may yield a different outcome...

235 points by mattyb 17y ago

I've only lived through one version control migration, that was from TFS to Subversion. The problem we have is the length of time Subversion takes doing updates, commits, and merges when you are dealing with a large repository and many changes spread out among files. (Good old TFS was fast.) Can anyone say if Mercurial is significantly faster? After going through Joel's tutorial it looks like Mercurial keeps history from branches in the root much better than either TFS or Subversion. I think I would opt for Mercurial the next time I have to set up source control.

j_baker 17y ago
Try out git. Force yourself to use it for a few weeks. I didn't like it at first. I used to be a Mercurial guy until I really learned git. I still don't know what it is, but there's something about git that just makes me want to love it.
kneath 17y ago
I can say without hesitation mercurial or git will be insanely faster for these operations. Remember, you work locally, and then push with hg/git. So when you do "git commit" it only relies on the speed of your hard drive/cpu. Commits happen instantly. Updates are needed very rarely (since you don't need to update to make new commits). Merges are so much faster it's not even funny. After merging in hg/git you wonder why SVN even had a merge functionality. In addition to those conceptual differences, the actual act of transferring files between remote and local on git/hg is also much faster than SVN. Entire checkouts of git repositories are usually smaller (disk size) than the equivalent SVN checkout... of one version. This means less time on the network all around.
- jackfoxy 17y ago
  Yeah, committing to your local copy better be fast, it's committing to the shared server repository that I'm concerned about.
  - chousuke 17y ago
    I think you'll find that whatever git does, it's faster than the corresponding operation in SVN. When you send commits to a remote server, git compresses them and sends the packfile over the network. The server will refuse non-fast forward merges (the branch you're pushing is supposed to be merged by you first, locally) so it pretty much has nothing to do but uncompress the changes and apply them. Unless you have a really slow network or are sending an insane number of commits, it's not going to take longer than a few seconds. Cloning big repositories (like emacs, with ~25 years of history) can take a while if you have a slow network, but sometimes it feels like git can actually clone a repository faster than SVN can check out a single revision. But repos like emacs' are rare. Often, SVN repositories end up being huge because they contain the code of many unrelated projects. In Git, having such a huge repository is impractical; each project should have its own repository. There is support for submodules though, so you can make a "master" repo that contains pointers to the child repositories, if you really have to.

revorad 17y ago

Blogging is hard to give up, Joel? Edit: Uh stop upvoting me please. That was a tongue-in-cheek comment and, as sant0sk1 pointed out below, also lazy on my part.

giu 17y ago
I think it's the last one. Tweeted 5 minutes ago by Joel (http://twitter.com/spolsky/status/10671213571 http://twitter.com/spolsky/status/10671213571): "The last Joel on Software article[...]"
spolsky 17y ago
Not at all! Today is the ten-year anniversary of my first real post, so I've been planning to have my last real post on 3/18 for a long time. Thanks for all your attention over the years. I'll still be around, just not doing these essays any more.
- revorad 17y ago
  Cool. I'm sure many will enjoy your archives for years to come.
- dugmartin 17y ago
  Thanks for all the work over the years. The silent majority is grateful.
- jswinghammer 17y ago
  Thank you for what you've been doing over the last ten years. I'm not sure what my career would look like without Joel on Software. It really helped shape my outlook and encouraged me to invest in reading and learning more about programming than I would have otherwise. I wish you nothing but the best with your new venture and with Fog Creek.
- Sukotto 17y ago
  Don't you think you'd be better off posting that "I've run the clock out" paragraph as it's own thing? It seems important enough to be it's own post. Thank you for all your articles. I've learned a lot from them over the years and consider them really first class. Hell, my printout of the Joel Test is one of the three things taped to my desk (The other two being Merlin Mann's 5 Inbox-zero words and "Your Company's App" by Eric Burke)

graywh 17y ago

"If you are using Subversion, stop it. Just stop. Subversion = Leeches. Mercurial and Git = Antibiotics." This is great. A few years ago, DVCS was weird and strange and SVN was the stuff. When people discover how awesome Git and Mercurial are, they stab SVN/CVS in the back.

axod 17y ago
Such is the life of hipsters.
kylemathews 17y ago
"stab SVN/CVS in the back"??? I'm not sure why you're borrowing an assassination metaphor to describe someone's shift in technology choices. Technology aren't people.
- graywh 17y ago
  Would you rather I'd said "throw X under the bus"?
  - pingswept 17y ago
    No one has to be executed here. How about "start using a different tool"?
Sukotto 17y ago
That's just life in technology as the tools improve. 1) Stop manually backing up versions, that's error-prone. Use RCS! 2) Stop using RCS, it doesn't scale. Use CVS! 3) Stop using CVS, it's too complicated. Use SVN! 4) Stop using SVN, it makes it hard to merge branches. Use Hg/GIT! ... And someday, we'll be saying 5) Stop using Hg/GIT. They ________. Use _______! Same thing for hardware, and languages, and frameworks... and just about everything. shrug
- axod 17y ago
  It's funny how it's usually easier to ditch X, and write Y from scratch, rather than try to improve X.

bruceboughton 17y ago

But how does thinking about changes rather than versions make things easier, Joel? You never quite explain...

axod 17y ago
A version is just a changeset, so for me, it makes little sense to claim "changes" are a completely different way of thinking than "versions". Perhaps it comes down to how you divide work up. I just don't like branches. They're mess.
- nuclear_eclipse 17y ago
  I think the biggest conceptual difference between looking at "versions" versus "changes" is that versions imply a linear, static, and/or sequential history of revisions. By instead thinking of changes, you get a more open concept of a malleable history, in which you have more freedom to change histories or branches. Eg, if you want to split the development branch (trunk?) into two competing experiments, and then discard the losing branch at the end, a linear history of version/revision numbers split between two branches seems limiting IMO. Eg2, if you are working on a new feature or set of code that you haven't yet pushed to the server, having an open stack of changes gives you the freedom to modify and improve those changes without cluttering the commit history. When you're done, you simply push the finalized set of changes on top of the target branch.
  - axod 17y ago
    For me though, the linear element of versions helps me since it mirrors how I work - linearly with a constantly increasing value of time.
    - aidenn0 17y ago
      So you never branch or merge?
      - 17y ago

steilpass 17y ago

"we developed a new way of developing software using if statements instead of branches." Is that critizing feature flags? Or is more to that?

axod 17y ago
It often makes sense to have 2 alternate implementations of a component in the same codebase, so you can switch between them at startup/during runtime, and compare them side by side. Something that isn't as easy to do if you create 2 separate branches.
- etherealG 17y ago
  I think a better solution is to have both features in branches, and have a 3rd branch which allows realtime switching between the 2. a nice upside is that you can merge changes to each feature up into the "combined" branch as they get stable, to test side by side. when you finally finish, you can leave feature a behind by merging b into your release, or vice versa. or maybe even merge both into mainline. sorry, the point I was trying to make is that cheap branching and merging is still an easier way to manage this situation than just ignoring branches altogether.
  - axod 17y ago
    In what way easier? A: Create separate branches, manage merging/updating unrelated changesets. B: Create 2 implementations of something in code, and manage nothing. I guess it depends on how easy it is to isolate the part you want to create 2 implementations of, so it may depend on what language you're using as well as how you architected things. Branching+Merging just seems like something extra I have to do, manage, and remember. Like filing. And I still can't see what benefit it gives for many cases. But that's fine I think... I just don't get it. Maybe I'm too old ;)
- barrkel 17y ago
  Well, if you have a well defined protocol / interface for your component, and you have a runtime versioning mechanism (something as simple differently named DLLs will do if you're at the C level), then you ought to be able to do both: put the new code in a separate branch, but still switch in the old code at runtime. An advantage of keeping an old code in its own branch is that it's less likely to become incompatible through random changes. In particular, I'm thinking of bug compatibility: there may be bugs you wish to fix in the new code, but you don't want to fix in the older code because of third-party dependencies.

omergertel 17y ago

It helped me to think about it in terms of connected graphs. Nodes are versions and arcs are changes. A path between two versions is the aggregation of changes. Merging then becomes walking down the same path, but starting from a different node. I start at my current version node, and I walk down your path of changes. It's very different than trying to merge two nodes. (This is just my mental model, no need to read into it more than that)

Aegean 17y ago

How this article got so much points I'll never know. Its some novice advice on version control. Why don't you read the git books, they'll tell you all about it in well-organized fashion: http://book.git-scm.com http://book.git-scm.com

SriniK 17y ago
yup.. seriously why so many points? common editors/superusers...
Aegean 17y ago
Agree: Upvote, Disagree: Downvote. That shouldn't be the way to go. I insist the article is novice advice. At least take the time to reply on how you find it original rather than simply downvote.

smokinn 17y ago

What an excellent way to go out. Great last article Joel.

praptak 17y ago

"The interesting part is that these systems think in terms of changes, not in terms of versions." Not git. Git's repository model is very strongly snapshot-oriented. Of course the whole machinery for supporting changesets exists in git, but it is built atop a system that actively avoids "thinking" in terms of changes. Linus on this: http://marc.info/?l=linux-kernel&m=111314792424707 http://marc.info/?l=linux-kernel&m=111314792424707

schacon 17y ago
The storage model does not - it is not file-delta based, like SVN and Mercurial. However, you as a developer can (and often do) think of the commits in terms of a changeset or "work introduced" - this is evident in tools that exist like 'rebase' which treats each commit in a branch as a patch and the collection of unique commits on that branch as a patch series and helps you transfer that series elsewhere. The 'cherry-pick' command is similar - it enforces your thinking of each commit as a changeset or patch to what came before it.
weavejester 17y ago
I don't think that link contradicts Joel. Git represents repositories as a network of diffs, not a linear history of versions.
- praptak 17y ago
  This is not true for git's object model (which I believe maps to Joel's "user model".) Quote The Git Book: "Subversion, CVS, Perforce, Mercurial and the like all use Delta Storage systems - they store the differences between one commit and the next. Git does not do this - it stores a snapshot of what all the files in your project look like in this tree structure each time you commit. This is a very important concept to understand when using Git." Source:http://book.git-scm.com/1_the_git_object_model.html http://book.git-scm.com/1_the_git_object_model.html However the diffs are there below the snapshot-based model as means of effectively storing and transmitting the snapshots.
  - nas 17y ago

ableal 17y ago

There's something bothering me about the hosannas to the power of merging changes. Isn't there an unspoken assumption that all your work is text files ? If we talk drawings, photos, whatever binary data is needed for a project - what happens ? Are the binary deltas as good as SVN's ? Even if the "binaries" are XML text - e.g. drawings in SVG - wouldn't I be out of luck trying to merge changes if 'Beth' added a squiggle and 'Cath' a square to different parts of the drawing ? (many tools, upon writing, reorder data 'ad lib'). Are there "merge tool" plug-ins ?

schacon 17y ago
Binaries are not merged - if histories diverge and one side changes but the other does not, it will choose the side that changes. If both sides change, it will record a conflict and you have to choose one side (or create a new binary that you tell the system is resolved). You can run an external merge tool with 'git mergetool' and there are over a dozen it knows how to run, but I don't know which of them will handle images. You can also use .gitattributes to help you diff binary files efficiently, but you still have to either choose one side or manually create a new binary. I mean, even a merge tool won't help much there - if you have images that changed on two different branches and you want to combine them, you have to fire up Photoshop or something anyways - that's almost always going to be a manual process. Though, in the four or so years I've been using Git (and the years before that with SVN and CVS and RCS) I don't remember having to do that very often - thus is the life of a coder, I suppose. The people who create and modify images for programs tend not to tread on each other. Also, this is really the same problem even for systems without solid branching capability, like SVN. If two people modify a binary image at the same time and one commits, then the other will get a merge conflict when they update and will have to solve the conflict in order to commit.

10ren 17y ago

It's a DAG. The arcs are diffs (edits).

fnid2 17y ago

So is Joel's blog apparently.

gruseom 17y ago
He implies in the last paragraph that it's his final post. Still, I think there's a point here. Writing, when you're that good at it, isn't so easy to give up. Also, the blog has been a huge part of Spolsky's success. So I bet he'll revive or continue it in some form before too long. Edit: I hope he does, too. I probably disagree with him more than half the time, but there are few other writers on software who consistently hold my attention, and almost no one who consistently makes me laugh.
- Periodic 17y ago
  I would be happy to seem him move to a more personal blog. Something that is a little more about his personal experiences with technology. It sounded like he didn't like the regularly-published business-oriented posts. I wouldn't mind a picture of Taco on each post.

swolchok 17y ago

That backpack anecdote is a play straight out of Guy Kawasaki's The Macintosh Way (http://www.amazon.com/MacIntosh-Way-Guy-Kawasaki/dp/0060973382/ref=sr_1_1?ie=UTF8&s=books&qid=1268951347&sr=8-1 http://www.amazon.com/MacIntosh-Way-Guy-Kawasaki/dp/00609733...), which is on Joel's recommended reading list for managers (http://www.joelonsoftware.com/articles/FogCreekMBACurriculum.html http://www.joelonsoftware.com/articles/FogCreekMBACurriculum...).

po 17y ago

What's wrong with a jalapeño bagel?

abalashov 17y ago

For me, it always has been and always will be a right tool for the job issue. We work on relatively small code bases with a very small team of people, not large, unwieldy open-source projects with hundreds of contributors. Primary interest is in a log of what has happened to the code chronologically, rather than applying/unapplying specific revisions/hunks frequently. No need whatsoever for people to run with their own branches. With those requirements, git, Hg or Darcs would all present far, far more headache than they're worth versus Subversion. In some other scenarios, the formula may yield a different outcome...