> In the past, version control was something that existed but you never had to think about.
I think this statement highlights the fact that there are really two camps of developers when it comes to version control software. The difference between the two is what they consider to be the primary artefact that they are working on.
One camp considers the primary artefact to be the source tree that they have in front of them. The other camp thinks that the history of that tree over time, as represented in the version control system, is the most important and valuable thing.
Where things get rough is when members of the 'source tree' camp have version control imposed on them, usually by some corporate policy change. For them, the version control system is just like a backup. Commit messages are perceived as valueless as the developer never expects to see them again, so quite often they will be blank. Any change to the workflow that gets between the developer and making a change to their source file is a hindrance.
I would not recommend that an organisation with developers who are primarily 'source tree'ers try to adopt git. As the parent says, it requires too much knowledge of the tool, change to workflow, and, above all, commitment to having the git repository represent a detailed history of the development process. For them, a simpler tool the stays out of the way is probably more suitable.
Thank you! Your post explains what I've been seeing at the day job.
We switched from a Subversion-like proprietary VCS to git about six months ago.
We needed to because the proprietary thing was a stupid waste of money (it was basically equivalent to Subversion in capabilities), and because its ability to do the sort of branching we found ourselves in need of was severely limited. So we switched to git.
We've had more than a little culture shock since then - and basically it's because we work in source-tree mode, and history is something you delve into only when you have to. In fact, when we moved to the new system (git on Github) we didn't even port history - we started the Github repos with a historyless copy of the source, and left the old stuff in the old system should anyone need to look at it. Github basically serves the role of the central repo in the old system.
We would never go back - git centred on Github is a vast improvement on the old system - but it's a bit too fully-featured for what we want from it, and has the problem you describe where we have to think too much about the tool's view of things.
The only change to my workflow coming from a little bit of SVN and a whole ton of CVS was pull and push. Other than that, you can work exactly as you did in CVS and SVN if you want to. Sure the commands are a bit different, but the workflow can be the same.
Only if you keep a clear picture in your head of the tool's view of your repo - in a manner that CVS/Svn does not require you to. Otherwise you are pretty much certain to shoot yourself in the foot, repeatedly. Source: watching our devs do precisely this.
That is a useful distinction. However it is possible to hold a middle view, i.e that while the "current source tree" is most important - it is what you build and deploy, what you are most likely to base future work upon; the history is also an important artefact, and more than just a backup.
I like a good code history, but not at the expense of good current code!
I think this statement highlights the fact that there are really two camps of developers when it comes to version control software. The difference between the two is what they consider to be the primary artefact that they are working on.
One camp considers the primary artefact to be the source tree that they have in front of them. The other camp thinks that the history of that tree over time, as represented in the version control system, is the most important and valuable thing.
Where things get rough is when members of the 'source tree' camp have version control imposed on them, usually by some corporate policy change. For them, the version control system is just like a backup. Commit messages are perceived as valueless as the developer never expects to see them again, so quite often they will be blank. Any change to the workflow that gets between the developer and making a change to their source file is a hindrance.
I would not recommend that an organisation with developers who are primarily 'source tree'ers try to adopt git. As the parent says, it requires too much knowledge of the tool, change to workflow, and, above all, commitment to having the git repository represent a detailed history of the development process. For them, a simpler tool the stays out of the way is probably more suitable.