how to work with Code Repositories, but for web development?

[SilverNodashi]

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?

 

[MielieSpoor]

There are obviously some basic concepts that you first need to grasp when it comes to source control.

All my experience is on TFS and I am pretty advanced in that regard and have worked a bit on SourceSafe, but the concepts are still the same.

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?

You would basically have you main source tree in which your source resides and you make changes on that level. As soon as you would be releasing a new version, you would typically label you code so that you know that if you get that label, you will get the source as it was when that label was created. When you create a release later on you just create another label.

I don't know what the capabilities of CVS is but TFS has got a feature called branching and its very powerfull if used correctly - althoug few people really use it. I could point you to some documentation for you to work through but that is more related to TFS but it will give you a good overview on source control structures and the reasoning behind it.

Source control should be a very important part and product in every dev house since the reward you get from a quality product is huge!

 

[rrh]

VCS

Look at Installing Subversion aka SVN. It's free, has a massive user base and has plenty of third-party tools associated with the product. Operationally it [deliberately] looks like CVS, but - under the hood - they are completely different animals.

There is also a free Subversion manual available at http://svnbook.red-bean.com/. I would recommend that you spend some time with the manual in order to get a feel for both Subversion and version control systems.

Incidentally. if you go the Subversion route, use the directory structure recommended in the manual. It has become a de facto standard, so all articles on Subversion are based on it.

The other alternative is GIT (by LinusTorvalds). The story is that he wrote Git when he found that merging the code changes from hundreds of sources was a major problem. I haven't tried the product, so am unable to comment.

 

[SilverNodashi]

Thanx MielieSpoor, you're steering me into the right direction already. Please share the documentation you have in mind, I'm sure it'll help a lot.

The main thing that I don't understand, how others do it effectively, is this:

I work on a project called mod_helloworld 1.3.3 (Joomla module in this case), and I need to make a minor change to one of the files: modules/mod_helloworld/views/greeting.php, to update some typo's for example. Do I need to now change the whole project to 1.3.4 ? OR, do I change this one file from version 1.0.0. to 1.0.1 ?
And, on this matter, does every file in the project follow the same version, or do I give each file their own version as well?

I know this is a grey area, but I chose to go 3 levels deep, 1st level is major changes (mainly changing the whole program), 2nd level for minor changes (adding, or enhancing existing functionality) , and 3rd for stuff like typo errors. I don't know if this is correct, since everyone (or every source on the internet at least) has their own opinion on this), but it works for me.

Sorry to be ignorant, but what exactly is TFS?

 

[MielieSpoor]

To version you product is diffirent to source control versioning. The source control store will keep its own version numbers and those kind of things - you don't need to worry about that. As a general principal follow the following guidelines when you version your product. It will make life a lot easier for yourself and make management a lot easier also.

A version number consists of 4 sections looking like this: 1.0.0.0
You got a Major Version (1)
Minor Version (First 0)
Build Number (Second 0)
Revision (Last 0)

To give you an example. The version number of the assemblies that shipped with .Net Framework 2 will have a version number like this: 2.0.50727
This version number says the following: Major Version 2, minor version 0 (there were no minor releases). Build Number 50727 (they use a date so this build number is the date 2005-07-27). Revision 0.

The revision would mainly be used if you do your build, but on the same day you discover an error that would need you to do another build. If they had to do 3 builds on 27 July for .Net 2, the version would've looked like this: 2.0.50727.3

Also. Try to always give all your assemblies in your product the same version number since they would be built together and they are essentially just smaller components of a bigger product. When you start to break you product into various individual modules that function independantly, the you version each module diffirently since the module's release cycle would be diffirent to each other.

That is version numbers. In you source control repository, I would highly advise against using version numbers in you folder structure since that will bind you to that. When you branch out of your main branch then you can use a version number to identify the branch but don't do that in you main branch. You Main branch in TFS(Team Foundation Server) would be a very simple structure to simply keep a struture to you code to make things easier for you.
A sample structure would be something like this: Project -> Branch -> Src

That will allow you to have all you source together and you simply just change a file when needed and when you decide to release you label the source but you don't need to change any directories because a version changed. Say you want to start on a few new features that should interfere with the development that is currently going on, then you would make a branch of you code. Say your main branch is called main your main branch source strucuture would look something like this: Project -> Main -> Src. Now you create a new branch for the new feature called Feature1. Your source structure would look something like this now:
Project
__-> Main
____ -> Src
__-> Feature1
____-> Src

When you are now finished developing on Feature1, you simply merge Feature1 back into Main and your Branch Feature1 can now be removed.

TFS is Team Foundation Server and is a team collaboration system which include source control and its being developed by Microsoft. TFS is replacing SourceSafe but its - most probably - the source control solution which the the most feature rich and powerful in the market.

If you've further questions. Send me a PM then I'll get back to you on email. If you send me a pm I can mail those docs to you.

Cheers!

 

[dequadin]

^ +1 good explanation

 

[Action]

My last company was using Netbeans as the IDE and a version control system to get it done.

 

[James]

The other alternative is GIT (by LinusTorvalds). The story is that he wrote Git when he found that merging the code changes from hundreds of sources was a major problem. I haven't tried the product, so am unable to comment.

If you are considering using GIT, I would personally recommend you go to GIThub. It is free if you don't mind your code publicly accessible and if you don't there is a small fee to pay. I also use SVN + Trac at work which is really good. Freelance stuff all done with GIThub.

 

[Shred]

VisualSVN Server + Tortoise SVN + AnkhSVN = all you need

 

[murraybiscuit]

beanstalk allows secure private online svn hosting with 3 users for free.