6 ms·

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?
      - axod 17y ago
        Extremely rarely. Only if I really have to. But even then, I still work linearly. A revision number makes sense for me.
        blasdel 17y ago
        Mercurial will make up linear incrementing revision numbers for your repository, it's the only DCVS to do so.
        etal 17y ago
        Other than Bazaar. But Mercurial might be the only one to support both styles fully -- each changeset gets a hash and also a revision number for the branch.
    - dasil003 17y ago
      Actually what's happening is the way you work mirrors your tools. I spent years using CVS, then years using Subversion, now I have almost 2 years of git under my belt. There is something appealing about numbered versions, but there is no significant benefit over unique hashes of versions, or rather, any small benefits of sequential numbers is vastly outweighed by the tremendous benefits of unique hashes. I don't think any developer would disagree that the ideal workflow is to do one thing after another sequentially. It's just that in the real world, reasons come up where you might need to create topic branches. Even if you rarely need that functionality, there's no reason to stick with a crippled system like subversion unless you really need the one feature that it's entire design philosophy optimizes (partial checkouts) more than solid fundamental changeset tracking and manipulation. I'm no zealot—you won't catch me advocating linux vs mac, emacs vs vi, or ruby vs java. In most technology choices there is a wide range of tradeoffs and considerations. However Subversion is one of those rare cases where the tech is fundamentally flawed and serious developers need to move on, whether it be git, mercurial, darcs, or whatever. Subversion has a few use cases, and if you are not a professional developer then maybe it's deficiencies aren't very relevant. However, if you're slinging code all day, version control is your bread and butter, it will stay with you across languages and platforms, so it's insane to stick with a crippled platform that will always be that way due to fundamental design flaws.
      - abstractbill 17y ago
        Actually what's happening is the way you work mirrors your tools. I don't think so. I've been using git for about a year, and I still practically never branch or merge. Switching from task to task has a cognitive overhead that I prefer not to pay.
        blasdel 17y ago
        You branch every time you pull, and merge every time you push, though in the simple linear case it will always be a fast-forward. Every repository is an independent branch.
  - timr 17y ago
    The first example is a red herring, and the second really doesn't have anything to do with the change vs. revision dichotomy. If you want to split trunk into competing experiments (and eventually discard one) using a "traditional" RCS like Subversion, you can do that. Easily. Worrying about the linear history of rev numbers would be like worrying about the ordering of hash tags in git. Just ignore them -- you always can get the change history of the branch on which you're working. The second example is a feature provided by distributed version-control, not the choice of "changes" over "revisions". It's maybe easier to implement distributed version control with the former paradigm, but it's not impossible in either case.
- raganwald 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". This supports his point. If you think that a version is a changeset, as opposed to thinking of a version as a monolithic collection of files, you have already achieved enlightenment.
- swannodette 17y ago
  What about topic branches? You have a cool idea and you don't want to break the main line of work. You at the same time want history of the development of this new cool idea. You also want to be able to continue to bring in critical work from the main line of work. I don't know Mercurial but I imagine it can handle it as well as Git. It's this feature that you'd have to pry from my cold dead hands. SVN now feels like a straight-jacket to me even when I'm working solo.
  - axod 17y ago
    >> "What about topic branches? You have a cool idea and you don't want to break the main line of work. You at the same time want history of the development of this new cool idea. You also want to be able to continue to bring in critical work from the main line of work." Why not just develop that new idea, without breaking the main line of work :/ Can you give an example of an idea you can't implement without breaking the main line of work?
    - eru 17y ago
      > Can you give an example of an idea you can't implement without breaking the main line of work? I guess you will always be able to refute any example. The important thing is: While you can put yourself under that restriction, you will pay for it.
- abstractbill 17y ago
  I don't like branches either (we've been using git for maybe a year now at justin.tv, so I've definitely had the opportunity to grow to like them). Actually I think one of the biggest reasons I don't like them is that they're a kind of "hidden state". If someone made a VCS (or just an interface to an existing VCS) where branches were just represented by different subdirectories in the filesystem, then I might use them more.
  - blasdel 17y ago
    You can do that just fine with git: just make multiple independent checkouts in the filesystem. I do it all the time.
  - spolsky 17y ago
    that's how it works in Mercurial, if you make your branches by cloning.
  - lutorm 17y ago
    That is how branching works in svn, you make a copy to another directory on the repository.
    - abstractbill 17y ago
      I know how svn branching works - I don't think I explained myself clearly. I'd love a RCS that would let me see every branch that currently exists without having to check them out. The branches would exist as directories on my local filesystem. Any file operations (doing a directory listing, or accessing a file) on these local directories would actually be doing RCS commands and pulling data over the network, but I wouldn't have to think about that anymore.
      - lutorm 17y ago
        If you checkout the svn root, you get all the branches as directories in your local filesystem. After that, it seems it would be the same as what you're saying. Besides, you can do svn ls to see the branches. I must be missing what you're getting at.
etherealG 17y ago
I think in this case a version is the changes along with the base they're applied to. Whereas a change set is a difference between 1 version and another. like a diff or delta.
MicahNance 17y ago
I don't think it matters as much how we think about it. What matters is that the implementation of the VCS "thinks" of them as changes, which results in the easier merging.
barrkel 17y ago
Once upon a time I designed a versioning system for an object graph. It was for an application framework that was meant to be designed in an IDE, and didn't have source code, per se (it did have little snippets of code). But designing it around graph deltas, rather than versions, was always the right thing to do: that much was self-evident. Even as I use svn today, I turn almost all my work into patches. For every bug I fix and every feature iteration, it gets turned into a patch. That way it's usually pretty easy if I have to apply it to an older branch for a hotfix or whatnot.
mattmcknight 17y ago
I don't really get that part, at least not with the way I use svn. I branch, I tag and I use patch sets, which have some similarity to changes. I read this bit http://hginit.com/02.html http://hginit.com/02.html from Joel's Mercurical intro, and it sounds a lot like how I use svn, except that the branches are on the server, so they are probably a little slower, with the positive tradeoff of being available to my team. The other bonus with dvcs is having local history without doing pushes, which I think is a bigger selling point (although I get something similar from my IDE). I generally hew to the extreme programming view of branching and continuous integration. Push early and push often. Browsing github, I seem to find a preponderance of projects where the branches are never push-ed back to a master copy. No matter what tool you are using, branches can introduce semantic changes that are hard to merge. To sum, DVCS not that big of a deal for the way many people already use CVCS, when you end up working with a centralized copy anyway.
DennisP 17y ago
He explains it more in the linked "HgInit" tutorial. An excerpt: Mercurial actually has a whole lot more information: it knows what each of us changed and can reapply those changes, rather than just looking at the final product and trying to guess how to put it together. For example, if I change a function a little bit, and then move it somewhere else, Subversion doesn’t really remember those steps, so when it comes time to merge, it might think that a new function just showed up out of the blue. Whereas Mercurial will remember those things separately: function changed, function moved, which means that if you also changed that function a little bit, it is much more likely that Mercurial will successfully merge our changes.
- nas 17y ago
  Yet git doesn't remember those things either and can still merge as well as hg (arguably better in some rename cases). What was his point again?
  - statictype 17y ago
    I thought his point was quite clear: Mercurial (and distributed vcs in general) make it easier to merge changes than svn.
cwp 17y ago
It doesn't. Joel is a little bit off base here, in that it makes no difference whether a VCS tracks snapshots or deltas. What does matter is whether it keeps track of merges. If you merge one branch into another, your VCS must record that information, so that future merges can be done correctly. SVN doesn't do this, Git and Mercurial do. (And note that Git stores snapshots, not changes.) Joel's absolute right about one thing, though. Being able to merge correctly and reliably make a huge difference. It's what makes the distributed part of DVCS possible. Without a central repository, branches happen a lot more often, and merging has to work right. The contortions that teams go through to prevent branches are a thing of the past.
- philjackson 17y ago
  Actually, since 1.5, svn does track merges.
  - cwp 17y ago
    CVS then. I haven't used either in years.
  - NickM 17y ago
    That's correct. However, there are still some significant issues with Subversion's merge tracking. There's an excellent blog post that summarizes these issues here: http://blogs.open.collab.net/svn/2008/07/subversion-merg.html http://blogs.open.collab.net/svn/2008/07/subversion-merg.htm...

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?
    - axod 17y ago
      Extremely rarely. Only if I really have to. But even then, I still work linearly. A revision number makes sense for me.
      - blasdel 17y ago
        Mercurial will make up linear incrementing revision numbers for your repository, it's the only DCVS to do so.
        etal 17y ago
        Other than Bazaar. But Mercurial might be the only one to support both styles fully -- each changeset gets a hash and also a revision number for the branch.
  - dasil003 17y ago
    Actually what's happening is the way you work mirrors your tools. I spent years using CVS, then years using Subversion, now I have almost 2 years of git under my belt. There is something appealing about numbered versions, but there is no significant benefit over unique hashes of versions, or rather, any small benefits of sequential numbers is vastly outweighed by the tremendous benefits of unique hashes. I don't think any developer would disagree that the ideal workflow is to do one thing after another sequentially. It's just that in the real world, reasons come up where you might need to create topic branches. Even if you rarely need that functionality, there's no reason to stick with a crippled system like subversion unless you really need the one feature that it's entire design philosophy optimizes (partial checkouts) more than solid fundamental changeset tracking and manipulation. I'm no zealot—you won't catch me advocating linux vs mac, emacs vs vi, or ruby vs java. In most technology choices there is a wide range of tradeoffs and considerations. However Subversion is one of those rare cases where the tech is fundamentally flawed and serious developers need to move on, whether it be git, mercurial, darcs, or whatever. Subversion has a few use cases, and if you are not a professional developer then maybe it's deficiencies aren't very relevant. However, if you're slinging code all day, version control is your bread and butter, it will stay with you across languages and platforms, so it's insane to stick with a crippled platform that will always be that way due to fundamental design flaws.
    - abstractbill 17y ago
      Actually what's happening is the way you work mirrors your tools. I don't think so. I've been using git for about a year, and I still practically never branch or merge. Switching from task to task has a cognitive overhead that I prefer not to pay.
      - blasdel 17y ago
        You branch every time you pull, and merge every time you push, though in the simple linear case it will always be a fast-forward. Every repository is an independent branch.
- timr 17y ago
  The first example is a red herring, and the second really doesn't have anything to do with the change vs. revision dichotomy. If you want to split trunk into competing experiments (and eventually discard one) using a "traditional" RCS like Subversion, you can do that. Easily. Worrying about the linear history of rev numbers would be like worrying about the ordering of hash tags in git. Just ignore them -- you always can get the change history of the branch on which you're working. The second example is a feature provided by distributed version-control, not the choice of "changes" over "revisions". It's maybe easier to implement distributed version control with the former paradigm, but it's not impossible in either case.
raganwald 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". This supports his point. If you think that a version is a changeset, as opposed to thinking of a version as a monolithic collection of files, you have already achieved enlightenment.
swannodette 17y ago
What about topic branches? You have a cool idea and you don't want to break the main line of work. You at the same time want history of the development of this new cool idea. You also want to be able to continue to bring in critical work from the main line of work. I don't know Mercurial but I imagine it can handle it as well as Git. It's this feature that you'd have to pry from my cold dead hands. SVN now feels like a straight-jacket to me even when I'm working solo.
- axod 17y ago
  >> "What about topic branches? You have a cool idea and you don't want to break the main line of work. You at the same time want history of the development of this new cool idea. You also want to be able to continue to bring in critical work from the main line of work." Why not just develop that new idea, without breaking the main line of work :/ Can you give an example of an idea you can't implement without breaking the main line of work?
  - eru 17y ago
    > Can you give an example of an idea you can't implement without breaking the main line of work? I guess you will always be able to refute any example. The important thing is: While you can put yourself under that restriction, you will pay for it.
abstractbill 17y ago
I don't like branches either (we've been using git for maybe a year now at justin.tv, so I've definitely had the opportunity to grow to like them). Actually I think one of the biggest reasons I don't like them is that they're a kind of "hidden state". If someone made a VCS (or just an interface to an existing VCS) where branches were just represented by different subdirectories in the filesystem, then I might use them more.
- blasdel 17y ago
  You can do that just fine with git: just make multiple independent checkouts in the filesystem. I do it all the time.
- spolsky 17y ago
  that's how it works in Mercurial, if you make your branches by cloning.
- lutorm 17y ago
  That is how branching works in svn, you make a copy to another directory on the repository.
  - abstractbill 17y ago
    I know how svn branching works - I don't think I explained myself clearly. I'd love a RCS that would let me see every branch that currently exists without having to check them out. The branches would exist as directories on my local filesystem. Any file operations (doing a directory listing, or accessing a file) on these local directories would actually be doing RCS commands and pulling data over the network, but I wouldn't have to think about that anymore.
    - lutorm 17y ago
      If you checkout the svn root, you get all the branches as directories in your local filesystem. After that, it seems it would be the same as what you're saying. Besides, you can do svn ls to see the branches. I must be missing what you're getting at.

etherealG 17y ago

I think in this case a version is the changes along with the base they're applied to. Whereas a change set is a difference between 1 version and another. like a diff or delta.

MicahNance 17y ago

I don't think it matters as much how we think about it. What matters is that the implementation of the VCS "thinks" of them as changes, which results in the easier merging.

barrkel 17y ago

Once upon a time I designed a versioning system for an object graph. It was for an application framework that was meant to be designed in an IDE, and didn't have source code, per se (it did have little snippets of code). But designing it around graph deltas, rather than versions, was always the right thing to do: that much was self-evident. Even as I use svn today, I turn almost all my work into patches. For every bug I fix and every feature iteration, it gets turned into a patch. That way it's usually pretty easy if I have to apply it to an older branch for a hotfix or whatnot.

mattmcknight 17y ago

I don't really get that part, at least not with the way I use svn. I branch, I tag and I use patch sets, which have some similarity to changes. I read this bit http://hginit.com/02.html http://hginit.com/02.html from Joel's Mercurical intro, and it sounds a lot like how I use svn, except that the branches are on the server, so they are probably a little slower, with the positive tradeoff of being available to my team. The other bonus with dvcs is having local history without doing pushes, which I think is a bigger selling point (although I get something similar from my IDE). I generally hew to the extreme programming view of branching and continuous integration. Push early and push often. Browsing github, I seem to find a preponderance of projects where the branches are never push-ed back to a master copy. No matter what tool you are using, branches can introduce semantic changes that are hard to merge. To sum, DVCS not that big of a deal for the way many people already use CVCS, when you end up working with a centralized copy anyway.

DennisP 17y ago

He explains it more in the linked "HgInit" tutorial. An excerpt: Mercurial actually has a whole lot more information: it knows what each of us changed and can reapply those changes, rather than just looking at the final product and trying to guess how to put it together. For example, if I change a function a little bit, and then move it somewhere else, Subversion doesn’t really remember those steps, so when it comes time to merge, it might think that a new function just showed up out of the blue. Whereas Mercurial will remember those things separately: function changed, function moved, which means that if you also changed that function a little bit, it is much more likely that Mercurial will successfully merge our changes.

nas 17y ago
Yet git doesn't remember those things either and can still merge as well as hg (arguably better in some rename cases). What was his point again?
- statictype 17y ago
  I thought his point was quite clear: Mercurial (and distributed vcs in general) make it easier to merge changes than svn.

cwp 17y ago

It doesn't. Joel is a little bit off base here, in that it makes no difference whether a VCS tracks snapshots or deltas. What does matter is whether it keeps track of merges. If you merge one branch into another, your VCS must record that information, so that future merges can be done correctly. SVN doesn't do this, Git and Mercurial do. (And note that Git stores snapshots, not changes.) Joel's absolute right about one thing, though. Being able to merge correctly and reliably make a huge difference. It's what makes the distributed part of DVCS possible. Without a central repository, branches happen a lot more often, and merging has to work right. The contortions that teams go through to prevent branches are a thing of the past.

philjackson 17y ago
Actually, since 1.5, svn does track merges.
- cwp 17y ago
  CVS then. I haven't used either in years.
- NickM 17y ago
  That's correct. However, there are still some significant issues with Subversion's merge tracking. There's an excellent blog post that summarizes these issues here: http://blogs.open.collab.net/svn/2008/07/subversion-merg.html http://blogs.open.collab.net/svn/2008/07/subversion-merg.htm...