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.
Perhaps it comes down to how you divide work up. I just don't like branches. They're mess.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
Besides, you can do svn ls to see the branches.
I must be missing what you're getting at.
Am I right?
I have a hard enough time remembering the state of a single trunk, let alone if I had several branches on the go at a time. I'd fail spectacularly at remembering which branch has what on it...
It's easier to just do:
* Never break the build / functionality of code (Good idea anyway)
* Architect your stuff well with minimal dependencies so you can
can swap in/out modules/components easily.