4 ms·

I think the biggest conceptual difference between looking at "versions" versus "changes" is that versions imply a linear, static, and/or sequential history of r

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.

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.