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
Received on Thu Nov 10 15:57:46 2005