On Fri, 4 Feb 2011 13:44:18 -0800
Brian Smith <[email protected]> wrote:
> For some personal sites, what I do is I actually have the fossil repo
> opened in the web directory.
> It's .htaccess'd off so that you can't get at it, even if you know it's there.
Any particular reason to keep the repo in the web directory? Wouldn't
putting it somewhere outside whatever security wrapper you have on the
web server make more sense?
> Then, I've got a cronjob that once every 15 minutes does a 'fossil
> update release'.
> Where 'release' is just a tag that I apply to checkins that I feel are
> ready. I could probably also have a 'vX.Y.Z' tag so that I could force
> it backwards too, but, they're just personal sites. :)
I've done this kind of thing with perforce for a couple of clients,
including automatically syncing to test, q/a and then production
servers.
> I could probably also wrap it in a script that did more complicated
> release logic, if I wanted.
Based on my experience, you don't really need much release logic in
the script. While mine was wrapped in a script, most of the script was
to parse the output of the update command to find
added/changed/deleted files to have the search engine
index/reindex/delete them.
Just create branches for the various sites in the release process
(test, q/a, production or whatever) have each site open on the
appropriate branch, with the repo autosyncing so the update command
will pull from the master, and then your release process can focus on
updating the branches in the master repo properly, and the web sites
will follow along automatically.
<mike
--
Mike Meyer <[email protected]> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
