| Posted by SoftDux, 02-11-2010, 06:42 AM | | Hi all,
I would like some suggestion on this matter please. I have never bothered using any code repositories / version control systems for our web development project, many cause I didn't know any better, and probably cause most of our projects don't really require that we need to keep a history of what has changed. i.e. a client wants to change something on their website, and we change it, whether it's cosmetics or code (normally PHP & MySQL).
But, I want to see if CVS, or maybe even a forge script (like in offerforge) could benefit met. Most of the time when we make changes to the code, we simply update the version, from say 1.2.2 to 1.2.3 and write the changes to a basic changelog, which in our case is a simple text file calles changelog.txt
But, how could I benefit from a CVS, ir similar system? And what would be best for this environment? I installed CVS on my CentOS server, but it seems that it's not just a matter of creating a tree and dumping code. I'm not too worried about multiple users at this stage. All our coding is currently stored on a CentOS 5.4 Samba server, so we can access to the code from either a Windows or Linux PC. Do I need anything more?
I started using eclipse+PHP a few months ago and I don't really use it to its full potential, so I'm sure I could benefit from it more.
So, the question is, what is a good recommended setup to go with? Web based access to all the files would be nice, then we could access it from outside the LAN on HTTPS.
And how do I use it to my benefit? For example, clientA wants to make changes to Project1. Now I have a Project1 in the CVS tree (is this the right terminology?), and make changes to file contacts.php - what now? Do I need to create a subfolder called 1.2.2 (for example), and add only the updated file in this folder, or do I copy the whole Project into the new folder?
2 weeks down the line I need to make changes to 8 files, what do I do now?
Does this make sense? I realize it could be beneficial to keep older files, but how does one structure it?
|
| Posted by TDS-chriss, 02-11-2010, 09:19 AM | | I'd suggest you look at subversion (svn). You can use it from the shell, combine with ssl and integrate with apache for easy http(s) access.
An excellent source of information on svn can be found here http://www.phptr.com/perens where you can download the book Subversion Version Control: Using the Subversion Version Control System in Development Projects along with a number of other excellent books published under an open source compatible book license.
(You can also sometimes find the print copies of these books at your local exclusive books store )
|
| Posted by mattle, 02-11-2010, 09:58 AM | | To me, the biggest benefit of using CVS on web design projects is the ability to have multiple "sandboxes" and work collaborately. There's also inherent safety that goes into using versioning software.
Here's a model of how I've used CVS on web projects:
Multi-developerEach Developer has a sandbox (ie, file area and corresponding virtual host). They do development here only. When finished, they check in their code changes. To get changes from other developers, they can perform cvs updates in their own areas.Then there is a master staging area. Periodically, the project leader will update this area--CVS will automatically merge changes from all the developers, and any conflicts are worked out here. This is also where all code changes are independantly tested.Once all changes have been confirmed and tested in the staging area, an update is performed in the live site, instantaneously pushing all changes out with minimal downtime/risk of errors on the live site.
Eclipse has support for CVS, Subversion and a cool add-on called "Remote System Explorer." That last one would allow your developers to edit files directly in their sandboxes on a remote server.
I'm not sure exactly what you envision for "web based access." Can you elaborate on what functions you'd like to perform through a web GUI?
Nope. You just make the changes and chek them in. CVS does all the versioning for you.
Same thing. Once you get used to it, versioning control is easy and totally natural
Part of versioning software is the ability to revert to previous revisions. I think most software packages use diffs instead of storing full copies of previous versions, but restoring is as simple as
|
| Posted by tim2718281, 02-11-2010, 10:12 AM | | No, you don't create new subfolders; the library control system looks after version control.
All library control systems I've used work in much the same way:
1) You can add new folders and files
2) You can check out files. The library control system will usually prevent two people checking out the same file at the same time.
3) After you make changes, you check in the changed versions. The library control system assigns a version tag. You can also give a text comment when you check the changed files back in, giving the reason for the change. Often the library control system will insert comments in the source code, so when you're editing a file, you can see exactly what version you're editing and its change history. That's only possible
when the code is in a format the library system can handle.
4) You or the build/release manager can assign a label to a version of a file. For example, "Release 1.2"
5) You can extract all files with a certain label. For example, you can extract all the files with label "Release 1.1".
So, Release 1.1 has gone live, and everyone is working on Release 1.2. But a bug is found in Release 1.1. The programmer checks out the Release 1.1 versions of the relevant files, fixes the bug, checks the changed files back in, and labels them "Release 1.1.1".
The build manager builds a new version of the project, using files at "Release 1.1.1"; usually the build mechanism will have some kind of tree, so if there is not a file with a release 1.1.1 version, the Release 1.1 version is used. Alternatively, some organisations prefer to label all the files used with "Release 1.1.1", even if the files have not changed from "Release 1.1".
After it is built, the Release 1.1.1 version is deployed into testing; and the testers pronounce judgement.
At some point the person managing the library control system may lock the label "Release 1.1.1" to prevent it being used any more.
Eventually the release manager might decide to deploy Release 1.1.1 into production.
Anyway, the point of all this is the developers do not need to worry about anything.
It's worth noting the you can use the library control system for all files - including SQL data definition files, and files of test data.
Some of the modern tools will automatically build, deploy and test new versions.
Generally, the library control system will allow "branching", to handle the situation where it's necessary for two people to have the same file checked out. Programmer A is developing new function, but a bug arises in production which Programmer B must fix. (Commercial vendors will make all sorts of claims about the ability of their product to automatically merge branched versions. Ignore them, you cannot rely on it working properly. It may be that the function change for release 1.2 has made the fix in 1.1.1 irrelevant.)
And like anything else in software development, there are religious wars - "my version control system is the best." But I've never found any major problems using whatever library control system I was required to use ... they all work.
|
| Posted by Adam-AEC, 02-11-2010, 11:00 AM | | I'd recommend git.
It's distributed by nature, which is nice if you want to work when you are offline (internet cafe, plane, bus?)It's branching support is greatHost your repos using gitorious, or host at Github and get a bunch of cool features (editing via web, callbacks, etc)
|
| Posted by DashV, 02-15-2010, 01:11 AM | | I second Git.
It's leaps and pounds better than CVS/SVN.
One important thing to add about Git: performance!
With a large software repository, it stands from the crowd.
|
|
 Add to Favourites
 Print this Article
|
