On Jul 16, 2007, at 07:54, Ionut Caval [ TreeWorks ] wrote:
> I have a working server of SVN, but the problem is that i don't
> know how to actually use the SVN with PHP.
>
> I was trying to do something like this:
> - all developers get the repository from repository files
> - they commit the changes to the same Samba server on which they
> can test it in the browser
>
> The problem appears when they are editing the same files and they
> want to test it. The web file is overwritten so only the last user
> can see the actual changes he made. Ofcourse that the changes other
> users have made are not lost but it is difficult to work like this.
>
> Do you have another solution? Please help me on this one.
It sounds like your developers are sharing a single Subversion
working copy on the server via a Samba share. That's not a good idea
and defeats much of the purpose of using Subversion. Each developer
needs his own working copy. You have a couple options: either each
developer has his own working copy on his own desktop machine, or
each developer has his own working copy somewhere on the central
development server and accesses that working copy over Samba or
similar protocol.
If the working copies are on the local developer machines, this will
be the fastest, but it also means that each developer will need to
set up his workstation as a web server with PHP support in order to
test the changes he is making before he commits them. If you use a
database like MySQL or PostgreSQL then you have to consider that as
well -- maybe each developer has his own database server, or maybe
the PHP app just connects to a central MySQL server. In the web
development company where I worked, we didn't go this route, because
we did not want to task the developers with managing their own
servers, and our sysadmins were too busy to keep that many servers up
to date
So we used the other strategy, where all developer working copies
were on the central development server. We had them in the
public_html directories of our home directories so we could access
them via http://dev.example.com/~username/project and our apps were
specially programmed to function correctly regardless where they were
on disk or how you accessed them in URL space. Via Samba we opened
the PHP files for editing on our local machines, and we could commit
back to the repository using TortoiseSVN or by logging in to the
development server via SSH and using command-line svn. In our setup,
everybody had their own working copy (or multiple working copies, as
desired by the developer), but we shared a common database, and
certain directories, like image upload directories or other files
that tied in directly with database content, were kept in a common
shared location on the server, and changes to these were handled
carefully, with emails to the entire development team alerting them
to upcoming changes. The problem with this server-side working copy
strategy is that it's slow, or it was slow for us -- slow to access
files over Samba, and quite slow to do Subversion operations like
commit, update, status. I suspect that our central server's RAM was
not sufficient, or that we had too many other services running on it,
and that it was therefore thrashing the disk cache. More RAM, faster
disks and/or having a dedicated working copy server would surely have
helped. But it depends on the size of your working copy and the
number of developers trying to do things at the same time. If your
working copies are small and you have only a couple developers, even
a small server might suffice. We had 10 developers who each had at
least one working copy of the projects they were working on, the
largest of which was 100MB, so we ran into speed issues.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jul 16 23:05:33 2007