[TxMt] Re: SVN?

[Jacob Rus]

Rob McBroom wrote:
> I deal with several web sites and I use subversion to manage them. It's 
> great at what it does, but…
> 
> In my opinion, it's completely the wrong tool for the "transfer these 
> updated files to the web server" part of the process, which I think is 
> what you're after. I still edit all web site files remotely using 
> Cyberduck (same clunky workflow as Transmit), Samba, DAV, SSHFS, etc.

And in my opinion, any process that emphasizes convenience over 
functionality so such a degree that it avoids a version control system 
in favor of making live changes on the server is completely the wrong 
process for the job. ;)

I hope I don't offend by asking: what do you expect someone to do when 
tweaking that file on the server, making those hundreds of small 
"stupid" changes, and something suddenly doesn't work?  If he hasn't 
saved each intermediate step, with diffs and logs, how does he revert 
the problematic edit?

> The problem, if you care, is this: If you have a copy of the files on 
> your local machine and you want to make some updates then push them to a 
> remote machine using Subversion, you have to "commit" your changes*. 
> Most of the changes you make are small and stupid and not worth 
> committing.

No, this is exactly the wrong idea.  Most of the changes you make are 
small and stupid and you won't have any clue what they were or why you 
made them 2 days later when one of them turns out to have broken 
something.  That's why every little change should be accompanied by some 
minimal commit message, and needs to let you see a diff, and roll back 
to the previous state.

> I also prefer not to commit changes until after I've tested 
> and know that I didn't break anything. Why keep track of mistakes, 
> right?

The better question is why *not* keep track of all the steps.  You keep 
track of the mistakes so you can more easily undo them.  If you could 
immediately catch every error right at the point you make it, that would 
be one thing, but bugs can be very subtle and hard to isolate.

> But of course, when dealing with web stuff, the changed files 
> need to be on the server in many cases in order to be tested, which if 
> you're using subversion to "transfer" them, brings us back to committing 
> files prematurely.

There is really no such thing as a premature commit.  Commits are free!

> Many people on this list continue to suggest Subversion as an answer in 
> a situation like yours, so maybe I'm missing something. If so, I'd love 
> to hear what it is.

Yes, what you're missing is that the process that you are suggesting is 
very fragile and failure-prone.  Small changes messing things up cause 
major headaches for everyone not using version control, and that's 
especially true if development is done on the server directly.  I'm not 
sure that Subversion is necessarily the best answer--there are many nice 
version control systems.

But for any project bigger than 4-5 files, there is no excuse not to use 
some version control system, IMO.  The little bit of inconvenience pays 
for itself many times over, as the developer stops worrying so much 
about breaking things, and can freely commit changes, secure in the 
knowledge that a known good state is only a quick revert away.

It is only the existing culture that keeps web designers from using 
version control systems.  Hopefully this culture will change, because it 
wastes huge amounts of time for the developers involved, when they have 
to use guessing and fiddling as a recovery mechanism after breaking stuff.

-Jacob