[TxMt] Re: SVN?

Fri Mar 30 16:52:55 UTC 2007

I thought I'd chip in to this conversation and offer my two cents..

I'm the lead developer for a new startup site, and we have about 5  
people accross the globe working on the same 45,000 lines of php code  
(that's excluding libraries, javascript, css and html)... I've set up  
Subversion/Trac/Buildbot to manage everything, and it's working great...

I've set up a main trunk on which all the developers are working on,  
committing their code updates, etc. Because multiple people can be  
working on the same module at once and they use the repository to  
send updates back and forth, there's no single revision that can  
qualify for the production server. So what I do is use the svn branch  
capabilities, creating a 'branch' for each major version of the site.  
This involves copying the entire trunk to a new branch, collecting  
'stable' revision numbers for each of the modules, and reverting the  
new branch to those revisions. Then I switch the sandbox on the  
production server to this new branch. If anything goes wrong, I can  
easily switch back to the previous branch which was working fine.

For major updates, I have a secondary 'beta' sandbox which runs on  
the same db, so I can switch that first, test it, and then switch the  
production server...

I demand that my developers do a commit at least once a day, even if  
they have unfinished code, all they have to do is put a note in the  
log. As Jacob said, commits are free. Plus, by using branches, I can  
push a 'small and stupid change' on the branch without updating  
anything else. If I want to change something on the server directly,  
again, I can commit that change on the branch (I just have to  
remember to mirror that change on the trunk, because it will be lost  
when I switch to a new version).

As for 'changing files directly on the server', I'm 100% against  
that. If you really want to monitor the changes as they happen (which  
you should), set up a local environment, or dedicate a subdomain of  
your site for development (and have the 'development' run on a  
different database). If you don't have the capability of doing that,  
then you're most likely running a fairly standard setup which you can  
easily replicate on a local machine, so again, just have a webserver  
running on localhost and check all your modifications there. Don't  
let that prevent you from committing early and often though, you  
don't have to update to the live server till you're done :)

As for bigger projects, using a tool like Trac and Buildbot is  
definitely indispensable. One of my developers insists on committing  
code with basic syntax errors in them, so atm I'm working on having  
buildbot run php -l (lint check) on every committed file, and email  
me and the developer if there are syntax errors in the committed  
code :) All of this integrates VERY well with subversion. (btw any  
help with buildbot is appreciated, though I know this is not a topic  
for this thread... shot in the dark. If you feel like you want to  
help a sysadmin-by-force out, i'd greatly appreciate it ;)

-2c

(btw I'm sort of learning as I go here, so if anyone has any  
suggestions, I'd be more than happy to hear them :)

PS. TextMate rocks. If this thing I'm working on takes off (I'll know  
in a year), I'll probably spend a year or so working for free on  
tools I like, and TM bundles are on the top of my list

Constantinos

On Mar 30, 2007, at 9:49 PM, Ethan H. Darling wrote:

> Jacob,
>
> I strongly agree with your statement about web designers/developers  
> not embracing version control.  That is why I'm trying to be as  
> counter-culture as possible.
> I just started a degree program for Website Development and  
> Management and I'm shocked to learn that at no point in time will  
> the curriculum topically address version control.
> So, I'm on my own and that is what triggered this thread.
> Your observation has really encouraged me to continue learning  
> about SVN and integrate it into my professional toolbox.
>
> Thanks,
>
> Ethan
>
> 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
>>
>>
>> _____________________________________________________________________ 
>> _
>> For new threads USE THIS: textmate at lists.macromates.com
>> (threading gets destroyed and the universe will collapse if you  
>> don't)
>> http://lists.macromates.com/mailman/listinfo/textmate
>
>
> ______________________________________________________________________
> For new threads USE THIS: textmate at lists.macromates.com
> (threading gets destroyed and the universe will collapse if you don't)
> http://lists.macromates.com/mailman/listinfo/textmate

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1288 bytes
Desc: not available
URL: <http://lists.macromates.com/textmate/attachments/20070330/982f553b/attachment.p7s>