ci.antiquatis.org

The Central Information system is envisioned at a repository of information and experience, from library books for general reading, a computer database to map topics and indices of the materials available, and interactive computer programs and instructional video “how-to's” to relate what we have learned, in sufficient detail that the system can almost become self-instructive.
Post Reply
User avatar
LoneBear
Legatus Legionis
Legatus Legionis
Posts: 3586
Joined: Thu Jul 22, 2004 12:38 am
Location: Utah
Contact:

ci.antiquatis.org

Post by LoneBear » Fri Sep 25, 2009 11:57 pm

This post is for Stage 2: CI programmers...

I've set up some structural information on ci.antiquatis.org...

Code: Select all

html
    config (can only be accessed via programs running on localhost)
        configuraiton.xml (configuration information on how to access DB, etc)
    script (Admin files area, must have SVN username/pass to access)
        configuration.php (dumps the configuration.xml in array format)
    core (core classes used for include/require--no executables)
    server (xml, json and other servers for ajax, etc)
I set up the script, core and server directories as working copies of the CI SubVersion repository, to make updates easy after program changes are commited. I plan to add a program in the script directory to run the SVN update command.

DO NOT EDIT, or FTP, into the core, server or script directories, as they are "versioned" file systems that are kept in sync with the CI repository. Changes will get clobbered the next time "update" runs. Instead, checkout a working copy from the repository, make and commit changes, then run the update to move the files into the html directories.

User avatar
LoneBear
Legatus Legionis
Legatus Legionis
Posts: 3586
Joined: Thu Jul 22, 2004 12:38 am
Location: Utah
Contact:

Re: ci.antiquatis.org

Post by LoneBear » Sat Sep 26, 2009 12:15 pm

I've added an index file to the 'script' directory, which has links to run an SVN update and phpDocumentor. Also created the /docs directory to hold the documentation.

User avatar
Tulan
Cellarius
Cellarius
Posts: 453
Joined: Wed Aug 31, 2005 8:04 pm
Location: Austin, TX
Contact:

Re: ci.antiquatis.org

Post by Tulan » Sun Sep 27, 2009 3:27 pm

I suggest we do something to move away from using SVN update to sync our working copies with the production box. It's terribly easy to have something go really bad while maintaining SVN revisions in the production, public facing web roots.

I generally have a local Linux Apache MySQL PHP stack running on my development machine with the localhost running directly out of my working copy. This way I can make changes and see them instantly before committing. I generally have a shell script with a few rsync commands in it with instructions to explicitly ignore all of the .svn directories so that stuff isn't on the production box.

rsync will sync the directories based on which files have been modified and exist on the client and host; terribly useful.

I know the server is a shared host, but, it would be tremendously useful if we could get rsync setup (which requires a shell, or a running instance of the rsync server, shell is generally much easier to setup).
Ah, you seek meaning? Then listen to the music, not the song. - Kosh Naranek

User avatar
LoneBear
Legatus Legionis
Legatus Legionis
Posts: 3586
Joined: Thu Jul 22, 2004 12:38 am
Location: Utah
Contact:

Re: ci.antiquatis.org

Post by LoneBear » Sun Sep 27, 2009 4:53 pm

Tulan wrote:I suggest we do something to move away from using SVN update to sync our working copies with the production box. It's terribly easy to have something go really bad while maintaining SVN revisions in the production, public facing web roots.
I want "production" isolated from development, and revertable, in case there are problems. The technique I am using with other clients is to export a tagged release to the production box, that has been fully tested. If there are problems, I can always back out to a prior revision with a single command. Just haven't got to the point of implementing that in CI yet.
Tulan wrote:I generally have a local Linux Apache MySQL PHP stack running on my development machine with the localhost running directly out of my working copy. This way I can make changes and see them instantly before committing. I generally have a shell script with a few rsync commands in it with instructions to explicitly ignore all of the .svn directories so that stuff isn't on the production box.
With NetBeans, I have a working copy (which has the .svn and nbproject files), and a "copy" directory, which is the html path to a virtual server on my localhost (ci.antiquatis.test, in my case). The html doesn't have any of the .svn or project tracking stuff, just the real files. NetBeans maintains the copy, automatically, so I can do my local testing before commiting changes.
Tulan wrote:rsync will sync the directories based on which files have been modified and exist on the client and host; terribly useful.
Well, that's what Subversion does, too, but you can revert any file back to its prior state, and it logs comments for changes. It also merges changes... if you modify one part of a file, and I modify another part, it will merge the changes, as long as there are no conflicts.
Tulan wrote:I know the server is a shared host, but, it would be tremendously useful if we could get rsync setup (which requires a shell, or a running instance of the rsync server, shell is generally much easier to setup).
I could see that for a test area, but anything the public is using needs production release controls. I'll see if I can install rsync.

User avatar
Tulan
Cellarius
Cellarius
Posts: 453
Joined: Wed Aug 31, 2005 8:04 pm
Location: Austin, TX
Contact:

Re: ci.antiquatis.org

Post by Tulan » Sun Sep 27, 2009 5:06 pm

LoneBear wrote:The technique I am using with other clients is to export a tagged release to the production box, that has been fully tested.
Yeah, that is exactly what I use; I just rsync out of the tagged directory (instead of exporting, and I exclude the .svn hidden dirs). I know rsync doesn't have any revision controls, but, if we keep changes limited to being checked in before being pushed we can revert and re-rsync to the reverted revision if needed.
Ah, you seek meaning? Then listen to the music, not the song. - Kosh Naranek

Post Reply