info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

How to structure my project?


From: Garvin Hicking
Subject: How to structure my project?
Date: 12 Jul 2001 15:07:00 +0200

 Salutations, info-cvs!


I have to manage a project with multiple users. This project is a PHP- 
Website with some graphics and mostly textpages.

I use the CVS-downloaded code as well on our production machine as on our  
testing machines.

The project has to be structured to contain a maintainable beta-version  
and the final-version. The final-version always has to be a stable release  
and must be editable at any point without too much problems (for  
hotfixing...common problem on a PHP-website, I think). All users have to  
use the beta-version for integrating new features. It is necessary, that  
these new features are accessable for any user, so they can't be only  
developed in a working directory.

At present I split up the project after importing the PHP-Code in two  
branches: A "final"-branch and a "beta"-branch. I was already told, that  
this is not the way to go, but I think I missed the point and did it  
though. Until now each user has its working directory with a final- and a  
beta-version. The users edits his files in the beta-version and after I  
decided that the new feature worked, I used a "cvs update -j beta" on the  
files in the final-directory which had to be updated with the new beta  
code.

I thought this worked well, but after some days of usage I had the  
problem, that files which were added in the beta-version and then updated  
to the final version never got updated, when they were later updated in  
the beta-version. CVS didn't updated those added files with the comment

"cvs: file was added in revision 'beta', but already exists" (or something  
like that).

And, as well, the revision numbers got pretty mixed up after using the  
update-command from another branch (like 1.1.1.1.4.3.2.1). And, all files  
I've added in the beta-branch show up in a local Attic-directory. How can  
I tell the CVS-process that those files should be placed in the 'real'  
directory and be no longer stored in the Attic?

So, how should I organize my branches/revision-trees? I already thought,  
that I maybe must run a new "cvs rtag" command after each update to the  
final-branch to get all the files to the same revision number, and then  
put the new sticky tag to the beta-version and then I could do new updates  
to both branches, but I think this is suboptimal as well.

Should I make the now existing final-branch the 'default'-branch and then  
add on a 'beta'-branch? So that the now existing final-branch is my main  
trunk and I have a split off beta-branch and can merge the new files from  
this branch to the trunk?

Or should I do it the other way round? Make the trunk as 'beta'-stage and  
split off a final-branch where I can merge in changes from the trunk?   
Following guidelines should be met:

* Easy to add new files to the final version
* Easy to modify the current final version without interfering with the  
beta version
* Easy to incorporate changes from the beta version into the final version
* Easy to use for programmers, who are not familar with cvs (say: always  
re-occuring patterns for cvs commands)

Thanks for your help...the sooner, the better for my now misleading  
project. ;-)

Garvin.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]