Announcement

Collapse
No announcement yet.

Clue: working-copy as apache site with autoupdate using post-commit

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Clue: working-copy as apache site with autoupdate using post-commit

    This is not a script, maybe a contribution.
    Fist, I want to say, that my english suxs.
    AUTOMATED COMMIT/UPDATE.

    We use default apache site as a working copy of the repo, and when a developer made a commit, "post-commit" script will do a "update" on the workingcopy directory updating your web dev.

    ADMIN: FEEL FREE TO EDIT MESSAGE AND TRANSLATE TO NORMAL PERSONS!!

    We are a small dev company, and by rule, ALL CHANGES must pass trough svn server, so here is how we use ubersvn for that.

    with repo made on ubersvn... (Im not going to explain how to create a repo in ubersvn)
    1) I use a different APACHE2, on port 80 (I think you can use same ubersvn apache install)
    2) I change apache to start as "ubersvn" user.
    3) go to default directory for apache (/var/www/)
    4) create (as ubersvn user) a directory... maybe as repo name...
    5)
    Code:
     cd /var/www/directory
    and do a checkout with this command:
    Code:
    svn co file:///var/lib/svn/ubersvn/REPONAME/trunk /var/www/directory
    * assuming file:///var/lib/svn/ubersvn/ as default ubersvn location of svn (look ubersvn repo path)
    6) Edit /var/lib/svn/ubersvn/REPONAME/hook/post-commit and into the lines "# START-CUSTOM-CODE" y "# STOP-CUSTOM-CODE" we add the command.
    svn up /var/www/REPONAME

    With this, we can go using a browser to http://ubersvnhost/REPONAME and we will see the content of the directory "trunk", so to make changes there, you must made a COMMIT, and the post-commit script, will UPDATE the /var/www/REPO as a working copy.
    Last edited by gabrielcz; 07-08-2011, 08:32 AM. Reason: change title.

  • #2
    This is a really bad idea to implement in any kind of production and/or public-facing website. I wouldn't even use it on my development copies.

    Comment


    • #3
      Hi Andy, assuming there are branches for dev/staging/etc what's the problem with having a pristine branch that is identical to production? At some point you're going to have a global rev in subversion that is identical to production anyways right?

      Comment


      • #4
        It looks like I misread the post as implying that it served the web content directly out of the repository. My mistake. I don't see how this differs significantly from the official way to do this per the Subversion FAQ.

        This completely falls apart once you have any compiled items on the website. For plain HTML, PHP, etc. it'll work, but anything more complex and this simply will not work. Even for just PHP, I would recommend using a CI server instead, so that some additional structure, notifications, automated testing, etc. can be built around this. In addition, if you have a large update, all other commits will be blocked until the post-commit finishes executing.

        I still would recommend heavily against using file:/// for the checkout, regardless. It implies some lax security around the repository itself.

        Comment


        • #5
          Ok cool. Was curious because I see people asking about version control and web publishing all the time and there are a few approaches.

          Comment

          Working...
          X