On Mar 29, 2007, at 3:50 PM, James Edward Gray II wrote:
On Mar 29, 2007, at 2:32 PM, Rob McBroom wrote:
Most of the changes you make are small and stupid and not worth committing.
I strongly disagree with that.
Subversion is a tool for working with changes, much like Address Book is a tool for working with addresses. It has numerous operations for those changes including reporting on what was changed, by who, when, and the reason they gave for the change. Of course, it can only help you with what it knows about, just like your Address Book.
The more you get into version control, the more you learn that those smaller changes are exactly what you want. You want to get it down to where each commit does just one thing, whether that's adding a new feature, fixing a bug, or just some copyediting. Subversion then becomes even more powerful because you can work with these changes individually.
Let me add a couple of things to all this: 1) Every svn commit comes with four key pieces of information: WHEN it happened, WHO did it, a DESCRIPTION of what the commit is about and WHAT has changed. You can then search for all this information. In the context of a project involving more than one person, all these are absolutely critical things, especially if the members in the team change. Case in point is all the bundles in TM. We can actually search in the repository to find who added a new command or changed a line in the code, and what their rationale behind it was. (This is btw why it is very important that the commit messages describe the situation of the change and why it happened, instead of the change itself) However, even in the context of a single person, it is a great source of information, especially when you get back to a project you were working on 2 years ago or so. It's the same reason we add comments to source code, because the actual code does not reveal much about the *context* in which it was written and the considerations that were going on through the developer's mind at the moment.
You can also determine, within a particular file, exactly who was the last person to change each individual line and when.
2) I would think that it is particularly important that you have a subversion system exactly when you do web stuff, where you need to check things on the actual server often. With a subversion system, you can update the server after you've committed the changes, and then if there are problems simply revert to the previous, known-to-be- working, version until you've worked out what went wrong. Even better, you have the production server and a development server. So after you commit your changes, you update the development server and test there, and if things work out then you also update the production server. The update command in this context would be a simple "svn up" running in the servers, regardless of what changes you've made, instead of a bunch of scp/rsync's. You can just turn it into a textmate command and activate it with the click of a button.
On the other hand, if you manually copy your changes to the server and then it turns out you have made a mistake and this version is not workable, how do you revert to the previous version? You'll have to figure out exactly what you changed and change it back. That would seem terribly inefficient to me, when a simple "svn revert" would do.
I am however not a web developer, so perhaps there is something I misunderstand there, otherwise I really don't see how anyone could work on a big web project without a versioning system. A versioning system provides a complete journal of what happened when and why, things that can be invaluable. I've actually started using it for math papers as well (well, my thesis actually. But I am thinking it could be a really nice way to collaborate, though a paper has somewhat different problems not really solved by a versioning system. Anyway, I digress ;) )
James Edward Gray II
Haris Skiadas Department of Mathematics and Computer Science Hanover College