[TxMt] Re: SVN?

[Charilaos Skiadas]

Before we continue down this road, let's be clear about what Rob is  
suggesting, because I was also mislead in my original responses by  
not reading his post carefully. Rob is not suggesting not to have  
version control. In fact, he already has it in all his servers. What  
he is saying is, what are the advantages of 1 over 2, where 1 and 2 are:

1) Having two checkouts of the repository, one local and one on the  
web server. Then making changes to the local version, committing and  
then updating the server side.
2) Having only a checkout of the repository on the web server, and  
remotely editing that checkout. Then testing, and only committing the  
changes if things work out. So he can still revert his changes.

So I think some of our points remain valid, but let's be clear about  
the issue. The issue is not version control or no version control,  
the issue is local checkout and not directly editing on the web  
server, versus direct editing on the web server.

Haris Skiadas
Department of Mathematics and Computer Science
Hanover College


On Mar 29, 2007, at 10:35 PM, Jacob Rus wrote:

> 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