On Friday 08 September 2006 23:49, Walter Hop wrote:
> Hi all,
>
> I am currently designing a SVN setup to use for our website and backend.
> This is the first time I am going to use SVN for a serious project, so
> I'd like to get it right the first time! I hope somebody with experience
> can give me some comments on the viability and possible pitfalls of a
> setup like this. I'll try to be as brief as possible!
Remember that subversion isn't designed to do "application deployment".
So it's a bit off-topic.
> My goals:
> 1) Develop on a test server, and do controlled deployments to the
> production server.
> 2) Do periodic releases where all changes from the test server are merged
> into a production release.
> 3) Support for doing "hotfixes" on the production server and backporting
> them to the development machine; this should be as easy and painless as
> possible.
We share the same goals, but we have other limitations:
a) the branwith between the repository and the live server is limited
b) the live site uses a database and you can't merge the development/test
database with the live database, so the database modifications need to
be done on the live site and then deployed on development/test server.
(actually using dump + rsync)
c) we use some external libraries but sometimes we need to fix bugs in
the external libraries, so we import those libraries in an external
subversion repository to get things less coupled
d) some files are dynamically generated by the application, and we have to
sync them without using subversion (using rsync)
In my experience you should forgot the goal number 3. Use a test server and
some script to write the glue for deploying to the live site starting from
the test server, and a script for sync the live database with the
developement/test database.
> - The various scripts and libraries under version control live in
> various locations on the production/test server. For instance, some
> files live in /usr/local/, some go into /www, some in /home et cetera.
> It seems I should make subdirectories in the repository, checkout the
> relevant parts of the repository at all the root points, and make a
> script to walk through all these directories on the production/test
> server and do a 'svn update' there. But can I also do the same for a
> commit, keeping all the created changes in one singular commit (instead
> of executing a 'svn ci' for every dir, creating several commits)?
No, AFAIKS the directories that are going to be checked in should have a
common parent that must be a directory under version control.
And what about user/permission management? Are you going to checkout all the
files as root?
By the way somethin seems wrong in your application layout, you shouldn't
use /home for your application files.
> - I would like to have developers use their own login/password when
> committing. But at the same time, they may be working from the
> test/production servers which always have an existing local copy (not
> checked out by the developer account itself). Someone gave me the
> suggestion to have the test/production servers checked out anonymously,
> so users would then be asked for their login while committing. Will this
> work? Is it also possible with a non-anonymously created local copy (for
> instance with a 'testserver' account)?
No, remind that the .svn directories belong to the user who made the co,
and that subversion place a .subversion directory in the user home directory
to remember user settings, sometimes too many settings (clear text password,
for example).
> - Merging changes to a different branch (releasing or backporting a
> hotfix) seems to require knowing the revision number of the first change
> after the previous merge. I think it's probably easiest to create a
> merge-script which merges in the specified direction and then stores the
> resulting revision number in a text file, so that the next merge in this
> direction will be from this point. So I'd have to keep track of two
> revision numbers for the latest trunk->release merge and the latest
> release->trunk merge. Is my thinking on this correct?
Yes, usually you should keep note of merging in the log message.
There is also a contrib script that helps, search for svnmerge.py
> - Are there any pitfalls in doing this kind of setup, or is there an
> easier way to go abou this than the scenario?
Start thinking about adding a test server and custom script(s) in your
deployment process.
> Sigh. I guess this message is long after all. Anyway, I've tried to
> google a bit for this kind of scenario, but I wasn't very succesful. Any
> tips would be welcome!
Yes, because it's really complicated and often application specific.
You could start looking at best pratices for well established
application/framework like ruby on rails, django etc..
Maybe others could share their best pratices, or simply arguments against
using subversion for application deployment.
Daniele
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Sep 9 13:09:28 2006