[TxMt] SVN?

[Rob McBroom]

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:

> 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.

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.