Training

22 Responses to “The Secret to Perfect Version Control”

1. Jeremy Dunck says (on April 18th, 2006 at 12:26 pm )

   Not to be too critical– the tips in the audio are useful– but suggesting that the above topics are well-covered in the 10 minute slot is overselling it a bit.

2. Ryan Carson says (on April 18th, 2006 at 4:16 pm )

   Hey Jeremy,

   I’m not sure where we said the topics were “well covered”. We intend for these training snippets to be small doses of goodness, not full masterclasses :)

3. TechMBA says (on April 18th, 2006 at 5:13 pm )

   You do too!!!

4. I Blogged This » Blog Archive » ThinkVitamin.com is Live! says (on April 18th, 2006 at 5:15 pm )

   […] “The Secret to Perfect Version Control” By Cal Henderson http://www.thinkvitamin.com/training/webapps/enterprise-web-apps/ […]

5. Lorewarden says (on April 19th, 2006 at 4:22 pm )

   You can’t call it “perfect version control” when they use cvs for version control, and directly edit files on a server via ftp. Cvs should be retired.

6. Ryan Carson says (on April 19th, 2006 at 5:50 pm )

   Lorewarden,

   They don’t edit files directly on the server. That’s exactly what Cal said not to do ;-)

   They use CVS (or Subversion) and then deploy to Dev, then Staging, then Production.

7. Ben Darlow says (on April 25th, 2006 at 8:56 am )

   These are kind of the procedures I’ve always assumed would be the right way of working with version control and web applications, but what I feel is perhaps missing are less theoretical concepts but more simply nitty-gritty implementational details, and how to get around the headaches and gotchas that deploying version control can bring up.

   For instance, at a previous employer I set up Subversion with our development server (there was no staging server, unfortunately) and then had a post-commit script updating a working copy which resided in the local server’s document root. The downside here is that in order to see changes (no matter how minor they were) a commit is necessary first. Synchronising the live site with this working copy was then performed using rsync, but this left the problem of there being no guarantee that site-breaking changes would be included in the update unless everyone in the team knew exactly what development changes were being made at the point an update was performed. Having a staging server sat in the middle mitigates this to an extent, but doesn’t remove the problem entirely, as bugs in staging could again be elevated to live with an inopportune sync.

   One possible solution which I considered was in making each user’s working copy a fully functional document root for a personal, individual development virtual host. In a unix environment this could be relatively easily achieved if you use your ~/public_html/whatever (or equivalent) directory as your working copy, and then have this configured to point to http://username.somehost/, but this would be a pain to administrate. Basically this seems to be the crux of the problem; the easier you make it for the developer, the harder it becomes for the administrator, and frequently in a lot of smaller shops these two people are one and the same.

   I’m still convinced that version control is absolutely vital for web application development, but I’m not yet convinced that shoehorning tools which are traditionally aimed at compiled software management is the answer.

8. rico says (on April 28th, 2006 at 2:05 am )

   Great! I’ve always used Subversion on my PHP projects myself. My staging sites (in a local network/machine) is always under SVN version control, I found it a really nifty thing to keep track of changes.

   One little caveat I’ve been trying to deal with, though, is updating the production site in a web host, when the host only offers updating files via FTP. (No shell access to do a svn checkout.) Anyone got any tips for a situation like this? :)

9. cal says (on April 28th, 2006 at 2:15 am )

   a good way to handle it, presuming your app isn’t *too* big, is to script it on your end to create a new folder, perform an svn export, upload the folder to your production server via ftp, then swap the current webroot with the newly uploaded one. this can be done in a few lines of perl (use activeperl on windows, regular perl comes with osx).

   this can take a while, so you probably only want to push changed files. this can be done with the ftp-rsync script which comes with the Net-FTP-Common package.

10. Colin Morris says (on May 31st, 2006 at 7:33 am )

    What we did was have:
    Dev, Staging, Public Staging (non-IP restricted, for client viewing) and Production - all identically set up barring system upgrades.
    A DSL (Definitive Software Library) set up with SVN.

    People had local web servers for developmental testing, and used Tortoise SVN to check them into the DSL. They could then SFTP the files to the Dev server (or use WinSCP’s sync to automatically keep dev in sync with local, set up to not copy .svn files) for Dev system testing. We then had a migration application (PHP/ UNIX) that would migrate repositories between the DSL and Staging/ Public Staging and Production. It’d keep a record of all versions that made it to what environments so roll-back for changes was a breeze. It auto-tagged changes going to those environments so that we had a record of Tag releases and Trunk developments. Autotags had to be specified as Major/Minor or Bugfix releases - giving each tag a vM.m.b name as standard.

    Migrations can be chosen to be Full Repository or Files Changed Since Current Version On Target Environment for speed/ data integrity. They could be scheduled and had a mini-workflow so only Approver Authorised migrations made it to production.

    Seems to work real well.

11. Google says (on June 22nd, 2006 at 2:23 am )

    Nah, it is the most low down and bullshit way of version control using CVS.

12. QADev says (on September 20th, 2006 at 11:26 am )

    Hello!

    I like the articles on thinkvitamin very much and thank for this one!

    So I’d like what kind of programs do people use to control versions? The platform is Windows, the opensourse or freeware is mostly appreciated.

    Thanks in advance.

13. QADev says (on October 23rd, 2006 at 7:10 am )

    To answer for my question by myself :)

    I tried one of most opensource CVS systems - WinCVS. I coudn’t say that I am charmed, but I think it can help a lot. It’s enough complicated (at least for me) but if you spend enough time to understand it you will be awarded.

    Thanks for the article anyway.

14. PedMeds says (on July 30th, 2007 at 6:50 pm )

    HiI have been using Win CVS for a number of years and it’s use of binary files is downright horrible. We have been thinking of changing to Subversion.Is it any better? Anyone?

15. Sean says (on August 2nd, 2007 at 7:45 am )

    I recommend you try one of the distributed SCM’s

    Mercurial is an excellent (opensource) SCM

    http://selenic.com/mercurial

16. Lyubomir Petrov says (on August 23rd, 2007 at 9:42 am )

    I’ve described my usercase, similar to this one, but with the differences that I store in the version control the db structure too.

    Here is the post:
    http://lpetrov.mylo.bg/index.php/2007/08/23/version-control-svn-php-and-mysql/

17. espresso online » Archive » Perfect version control says (on November 7th, 2007 at 9:48 pm )

    […] http://www.thinkvitamin.com/training/webapps/enterprise-web-apps/ […]

18. Mark says (on November 8th, 2007 at 1:33 am )

    I saw a post about Perfect Version Control and then realized it wasn’t about Accurev. Odd.

19. haber saati says (on November 12th, 2007 at 4:11 pm )

    you should enable “view source” code on example projects

20. sohbet says (on November 12th, 2007 at 6:40 pm )

    tesekkürler

21. Chat says (on January 22nd, 2008 at 3:36 pm )

    I Think İt is Very good information ….
    Thanks…

22. Webmaster says (on January 23rd, 2008 at 11:16 pm )

    I think you did a great job of pointing out the major strengths and weaknesses of the book.