I am just finishing a Django project that is managed by Subversion. I
have set up 3 web sites to manage it - a "development", "staging" and
"production" server. This is a common paradigm, nothing that I came up
with myself.
You can have active committing by developers to the repository and there
are no problems. Just check out a particular revision onto the the
staging server and test that everything works as expected. When you are
confident that everything is OK (for that revision), you can check out
the same revision on the production server (effectively performing an
"upgrade").
Each web server requires a slightly different settings.py file since you
want each to use their own databases, but most of the content of these
files will be the same. I even use Subversion to manage these 3
settings files in the same repository. I have 3 settings files:
settings_development.py
settings_staging.py
settings_production.py
When updating one of the servers with a particular revision, all of
these files are downloaded to the particular server you are dealing
with. To use the appropriate settings file, I create a symbolic link:
settings.py
that points the the appropriate settings file. You can get by without
introducing this link by referencing the appropriate settings file in
each Apache Virtual Server configuration, but if you want Django's
"manage.py" script to work transparently, you need this link.
The important thing is to *NOT* put this link under revision control,
i.e., it is not managed by the Subversion repository. It will stick
around while the other files in the directory are being managed by
Subversion.
Jeff
Aidas Bendoraitis wrote:
> I have an SVN-specific question which doesn't really fit into Django
> groups. Anyway, maybe somebody of you will have enough experience and
> competence to answer it.
>
> We are going to set our Django projects under
> version control on a dedicated server. We will also publicly run
> several Django websites on the same server. So what is a better
> practice -- to use the code under source
> control for the public websites directly, or to have copies (tags) of
> the subversioned code for the public websites?
>
> How is this managed with djangoproject.com and djangobook.com?
>
> Regards,
> Aidas Bendoraitis aka Archatas
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
