On Mar 29, 2007, at 4:44 PM, s.ross wrote:
Are you committing things to SVN, copying to a Web server, and *only then* discovering a missing semicolon?
No, because as I'm sure you'll agree, that would be stupid. :) I gave that as an example of why *not* to use Subversion in this situation.
Many developers use a process like this:
- checkout
- modify
- test
- checkin
- prop
If you do the "test" part, the "ok, crap I forgot the semicolon" comments won't crop up as much.
Yes, this is exactly the process I follow. The issue here is that the "test" part can't happen until the files on the web server have been updated. Ergo, Subversion is not the right way to update those files because that would put "checkin" before "test".
To be more explicit, I keep the working copy on the web server rather than on my local machine and use some kind of remote filesystem to access it. I don't generally have local copies of any of these files. Perhaps that will clear up some confusion.
On Mar 29, 2007, at 4:38 PM, Charilaos Skiadas wrote:
- 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.
OK, but whether I commit my new crappy changes or not, the old "known good" version was previously committed and I can therefore revert to it, so I'm not sure what you're getting at. When I think changes are good, I commit them. If subsequent changes were a horrible mistake, I can revert. If I committed every single change, as you seem to be suggesting, then I could revert to previous good versions and previous bad versions, but why would I ever want to do the latter?
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.
Or better still, make changes to the dev site directly. When they've been tested and verified, commit them and use a post-commit hook to "svn up" the production site.
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.
Like I said, the changes in my case are happening to a Subversion working copy *on the server*, so I can revert and diff and all that good stuff.
--- Rob McBroom http://www.skurfer.com/ I didn't "switch" to Apple... my OS did.