in reply to Perl apps and version control

If you have to alter files post-production, you should do that in the templates and alter the (one) template, or use the <TMPL_INCLUDE feature to build your templates from smaller parts. Consider creating your Javascript files from templates as well. You don't need to render the templates live ("fry"), you can just create them on a new release ("bake") and then copy the resulting files to a static directory on the webserver.

I don't see any version control making this simultaneous editing easier. I'm fond of git, because it has very little administrative overhead.

Replies are listed 'Best First'.
Re^2: Perl apps and version control
by BioLion (Curate) on Sep 21, 2010 at 08:56 UTC

    Seconded. the wonders of github also make sharing/access easier. Corion's advice about static releases is good advice too - OP doesn't want to get sucked into cycles of releases and bufixes. Making static releases I always find makes you *think* more about the release, which is always a good thing...

    Just my too sense.

    Just a something something...
[reply]
      I'd have to install git locally, can't use github online from our servers. Thanks
[reply]
Re^2: Perl apps and version control
by Anonymous Monk on Sep 21, 2010 at 10:17 UTC
    Will git take the pain out of rolling things out? I have multiple sites over two test environments and a live environment?
[reply]

      Not better than any other revision control system. I would do the distribution through rsync or some other distribution mechanism. Just check out the "tested good" state and use rsync to distribute it across all machines, or directly check out the "tested good" state on each machine through git, depending on your network setup.

[reply]
[d/l]
[select]
        This is very good advice. I've been also exploring the idea of automating the revision updates (svn in my case) by writing some Perl code.
[reply]

In Section Seekers of Perl Wisdom