A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I started using Subversion a while ago for school projects just to get a feel for it. The small amount of time I spent setting it up was already paid back many times over while writing my compiler. (stuff like, "this was working last night, why isn't it now? *diff* ooooh, I changed those variable names)
However, I also had to develop a web application for software engineering class, and I couldn't really reconcile all the different file locations and configuration files that needed to be maintained.
For example, you might have:
SQL database definitions - these need to be kept somewhere but you have to alter them if you alter the database, or run the SQL file if you've updated it directly.
Actual database contents - sometimes you have to make fake data to test some pathological case, or use the real data to see if the program works as expected
Source files - php, pl, asp, py, whatever files that actually run the app
Configuration files - for example, I use a db.php that contains the code to connect to the database, but it has to be different on my local dev machine vs. the remote target server
So how do you manage these unwieldy collections of files?
Tuesday, May 31, 2005
==>So how do you manage these unwieldy collections of files?
It's called "being a professional". Everything in the source repository. Everything.
==>For example, you might have: SQL database definitions - these need to be kept somewhere
We keep 'em in the repository
==> but you have to alter them if you alter the database,
You shouldn't be altering the database directly. Only through script files, and those script files are in the repository.
==>Actual database contents - sometimes you have to make fake data to test some pathological case,
"fake data" (a.k.a. test data) is entered via a script, and the script is in the repository. We use SQL Server, so it's easy to setup test data by hand, and spew it out into an XML file that can be loaded easily for testing "fake" scenarios. The XML data file is in the repository. The script to load the XML data file is in the repository.
==> or use the real data to see if the program works as expected
Well ... that's the one exception to the "Everything in source control" rule. We don't keep user data in the repository, however we do keep static system data and initial populations for lookup lists/tables in the repository. User data is stored in the database and kept in a library of backups.
Incidentally, you'll want to write a number of scripts that grab particular elements out of your production database and pull it to your DEV/TEST database -- e.g. pull a given customer and all employess, orders, products, shipments etc. that are related to the customer. You'll use these a lot.
==> Source files - php, pl, asp, py, whatever files that actually run the app
In the repository.
Don't forget your server config that has really nothing to do with the particular site/development effort you're working on. For example, in my world, once we setup a site in IIS, we script the config for the site so it can be created in a snap from the script. This script goes in the repository.
==>Configuration files - for example, I use a db.php that contains the code to connect to the database, but it has to be different on my local dev machine vs. the remote target server
In the repository. Both versions (your personal version, and the production version.
That's why we have source control. It gives us a nice way to manage all this stuff, and keep it consistent.
Attempting to keep track of this stuff w/out source control is a quick trip to the insane asylum.
Sarge is 100% correct.
If you lost everything but your repository, would you be able to build/deploy/test/use your application? If the answer is "yes", then you're doing it correctly.
For database stuff, I have it check the server path. If it's running on a server referenced as localhost (my local dev box) then it connects to dev... otherwise do production. Vary this one as necessary.
Tuesday, May 31, 2005
The usual thing to do with web applications in SCM is to have scripts to install them, this way you also have a reproducible setup system.
Tuesday, May 31, 2005
"Configuration files - for example, I use a db.php that contains the code to connect to the database, but it has to be different on my local dev machine vs. the remote target server"
I have a single configuration file that contains information for each host the site runs on. It sense at runtime which host its running on uses the appropriate configuration.
This saves a lot of headaches.
Yup, everything in version control. The problem of getting all the files back out to where they need to be is one of scripts. Personally I tend to go for a combination of make,rsync and perl for the special cases...
Wednesday, June 01, 2005
You're lucky you're using Subversion! Here we pay big bucks for PVCS that stopped evolving about the same time RCS did.
Everything said here is right on track. You will be happy that you scripted everything.
I'm at a bank, so we would not pull production data to a lesser environment, but most other things apply.
Thursday, June 02, 2005
I am using IIS, coldfusion, php and mysql and i am trying to figure out some way of using version control but not sure which will be the best way to go in windows based systems
Thursday, June 02, 2005
I can't speak to the Windows world, but I have an app built on Linux, specifically Debian, that works wonderfully.
First, everything needed to get the app started from the beginning is in our source tree.
Second, we use Debian packages for all installations.
The database updates are handled via the package system, automatically. We keep 2 sets of SQL scripts around - 1 to create the database and initialize it, and 1 to update from one released version to another.
I have spent a decent amount of time getting the package system all working, but that measn that everything about how to install the system is documented in, at least, code, and we actually use that method on a regular basis, so it gets tested, both of which are critical aspects of this.
I'm not sure which aspect of version control you're concerned about, but if you're new to version control, I'd highly recommend installing SVN for Windows with the Tortoise SVN client. Just install it on your own machine and use a local repository. Then get "Pragmatic Version Control using Subversion" ( http://www.pragmaticprogrammer.com/titles/svn/ ). If your experience is like mine, then pretty soon you'll wonder how you ever did without it.
Sunday, June 05, 2005
I would keep everything in version control (since you already know Subversion I would stick with that). For my projects using <a href="http://www.rubyonrails.org/">Ruby on Rails</a> I keep all of the files under Subversion control (the scripts I use to generate the MySQL DB, images, .rb files, .rhtml files, .css, project outlines, UI mock-ups, etc).
At work we keep 3rd party libraries under version control as well (this includes binaries to which you do not have the source code as well as the documentation associated with each version of the library).
Monday, June 06, 2005
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz