Version Control without SVN/CVS
Moderator: General Moderators
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Version Control without SVN/CVS
I've been lassoed into helping maintain this website, which recently had to (essentially) start from scratch because a cracker managed to gain FTP access and deleted our configuration files. Since the install was heavily modded, we weren't able to regenerate the config file and gave up.
It occurs to me that this could have been prevented if 1. Better backup policies had been instated (the site had not been backed up once previously) or 2. Version control on configuration files had been used. The second option, to me, is preferable, because there are multiple admins for the website, and version control would help keep a changelog and make it extremely easy to revert back to earlier versions if a well-meaning admin accidently crashes the application.
Unfortunantely, the webhost we are currently on does not offer version control of any type. I do have access to servers that do have SVN, but due to relatively high developer turnover rates (four years max), that is not an option, as I will be gone in a year and a half.
So, what I'd like to do is have a version-control-like set of policies that emulate SVN as best as possible. It's surely going to be a pain, after all, that's why they wrote CVS/SVN. But has anyone had experience with this sort of situation?
It occurs to me that this could have been prevented if 1. Better backup policies had been instated (the site had not been backed up once previously) or 2. Version control on configuration files had been used. The second option, to me, is preferable, because there are multiple admins for the website, and version control would help keep a changelog and make it extremely easy to revert back to earlier versions if a well-meaning admin accidently crashes the application.
Unfortunantely, the webhost we are currently on does not offer version control of any type. I do have access to servers that do have SVN, but due to relatively high developer turnover rates (four years max), that is not an option, as I will be gone in a year and a half.
So, what I'd like to do is have a version-control-like set of policies that emulate SVN as best as possible. It's surely going to be a pain, after all, that's why they wrote CVS/SVN. But has anyone had experience with this sort of situation?
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
See, the one that are free require the files to be open source (which is not possible for configuration files), and the ones that are paid... well... it would be more economical just to switch webhosts then. Furthermore, the webhost I'm on doesn't even have the Subversion binaries, so updating from the repository would require tarring the files (quite a pain).
The long term idea is to switch to a more robust webhost. But for now...
The long term idea is to switch to a more robust webhost. But for now...
From what you have said I would say your solution is to backup every day manually till you can afford to change hosts and install subversion. Or people upload to a staging site and everytime you upload to production you first make a backup. The staging site could just be a subdirectory of your site.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
That sounds like an interesting solution, but doing full disk backups is not feasible since the entire website is over 400 MB large. I'm currently attempting to restructure things so that I can simply backup a folder, and the rest of it is just application files that we can download again.
But this leads to the logical conclusion: take the configuration file we're talking about, and go about doing things like this: when you want to make an edit, copy the file to config.xx.php where xx is the largest previous revision number + 1, and then make your edits. Optionally move it to another folder so they don't pile up. For complicated things, like a directory of skin data, tarball the entire folder.
You'd also have a changelog file, which developers must update when they make changes, with files (and revisions) changed, date changed, and description of changes.
In short, a lot of developer discipline is required. I wonder if such a plan would actually prove to be workable.
But this leads to the logical conclusion: take the configuration file we're talking about, and go about doing things like this: when you want to make an edit, copy the file to config.xx.php where xx is the largest previous revision number + 1, and then make your edits. Optionally move it to another folder so they don't pile up. For complicated things, like a directory of skin data, tarball the entire folder.
You'd also have a changelog file, which developers must update when they make changes, with files (and revisions) changed, date changed, and description of changes.
In short, a lot of developer discipline is required. I wonder if such a plan would actually prove to be workable.