CVS for regional manifestations of a site

[Stefan Schwarzer <st...@grid.unep.ch>]

Hi list,

after taking the first plunge into the world of CVS, I would like to  
ask you - the experienced users - for advice. I searched quite some  
time on the Internet to find some information about the basics of CVS  
and read lots of documents. So, the principle(s) I do understand. But  
I didn't really find the answer to my - perhaps a bit specific -  
problem, although I had the impression that subversion was hinting in  
its document into this direction.

But here is my situation:

We have developed a site with something like 80 (mostly php) files, a  
mysql database and some other stuff covering global information. Now,  
this site has so much success in our organisation that regional  
manifestations of the "portal" are planned for different regions of  
the world. These do use the "global" code. But some adoptions have to  
be made within the code to reflect the regional scale of the site.

Here is my question: Beside the fact that these regional developers  
could contribute to ameliorate the code (via a CVS), more  
importantly: can the issue of the insertion & replacement of certain  
pieces of code be solved by using a CVS when the regions update  
theirs sites with the latest "global" version?

I hope I could make the point clear enough...

I would be grateful for any advice.

Thanks a lot.

Stef


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: CVS for regional manifestations of a site

[Ryan Schmidt <su...@ryandesign.com>]

On Nov 10, 2005, at 11:49, Stefan Schwarzer wrote:

> after taking the first plunge into the world of CVS, I would like  
> to ask you - the experienced users - for advice. I searched quite  
> some time on the Internet to find some information about the basics  
> of CVS and read lots of documents. So, the principle(s) I do  
> understand. But I didn't really find the answer to my - perhaps a  
> bit specific - problem, although I had the impression that  
> subversion was hinting in its document into this direction.
>
> But here is my situation:
>
> We have developed a site with something like 80 (mostly php) files,  
> a mysql database and some other stuff covering global information.  
> Now, this site has so much success in our organisation that  
> regional manifestations of the "portal" are planned for different  
> regions of the world. These do use the "global" code. But some  
> adoptions have to be made within the code to reflect the regional  
> scale of the site.
>
> Here is my question: Beside the fact that these regional developers  
> could contribute to ameliorate the code (via a CVS), more  
> importantly: can the issue of the insertion & replacement of  
> certain pieces of code be solved by using a CVS when the regions  
> update theirs sites with the latest "global" version?

Assuming you are in fact using the Subversion software and not the  
CVS software....

There are many ways to handle such a situation. If your code is  
abstracted in such a way that there's a base set of stuff that the  
regional sites can use unmodified, and then just need to add  
configuration files to control their specific behavior, then you can  
just keep their configuration files in a directory in the repository  
and after checking the project out, copy, for example,  
config.region5.inc.php to config.inc.php to activate it for that  
working copy.

I suspect your regions want to do a bit more mucking around. You  
could consider externals, but this also requires that the shared code  
live in exactly one place in the repository and not be modified for  
the projects that use it.

What you may want to do is copy your portal code for each region, and  
then merge back changes from the mainline. The idea would be that you  
have, say, version 1 of your portal that's finished and you tag it.  
You then use Subversion to copy it to a new place in the repository  
for each region. Programmers can modify each region's code separately  
and as much as they want to customize it, while development of the  
main software continues until at some point you're done with version  
2 and you tag that. At this point each region can decide separately  
whether they want to upgrade to version 2. If so, they use svn merge  
to merge the changes from version 1 to version 2 into their local  
copy. They manually resolve any conflicts that occur as a result of  
their previous  customizations and then commit that, and then that  
region is updated to version 2.

You can read about externals, merging and everything else in the  
Subversion book:

http://svnbook.red-bean.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org