[Top][All Lists]
[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.
- How to structure my project?,
Garvin Hicking <=