Thank u for your answer,
I completely appreciate all your points referring to the proper use of
The issue is that svn is not adapted to support web applications that
web-servers. You have to export from repository to the web directory
often to update the operational site (no checkin). Also web-applications
live, be developed and tested on developers workstations.
I found that having a WC being the same as /var/www/wc was unproductive
as a lot
of the svn files were deleted by the developers during debugging. So I
had to resort
to a way of managing revisions centrally and allow for a loose
depending on individual preferences. It is another way of thinking about
And a lot of sunshine from us here in Athens,
to all of u
Στις 13-04-2011, ημέρα Τετ, και ώρα 11:34 +0200, ο/η Thorsten Schöning
> Guten Tag Peter_at_locotel,
> am Mittwoch, 13. April 2011 um 10:33 schrieben Sie:
> > The development in not done on my working copy. It is done by my
> > developers and
> > testing programs are uploaded to the web server preview directory so
> > they can be
> > tested in real scenarios and test users. If tests are successful, these
> > program are copied
> > to the public part of the web server and used by all other users.
> > I want periodically to update repository and keep revisions
> > from /var/www of the web server.
> I don't think you should work that way at all. What you get are
> backups of /var/www, but this is easier to realize than using
> Subversion: Just copy/tar/whatever the directory using cron.
> Subversion won't be of any real benefit in your scenario, but will
> likely produce problems. It's of no benefit because the changes you
> get between your copies to subversion will be somewhat large and
> therefore hard to understand in case of errors. But in case of any
> errors you want to find those quickly. Even your log messages won't be
> of any help because you just don't know what has changed, you can just
> produce timestamps oir stuff like that, but that's what Subversion
> already provides. The problems may arise during deleted and added
> directories. Normally a developer would delete and add, move or
> whatever directories using a svn client and therefore telling
> Subversion exactly what gets deleted, moved etc. In your case there's
> no such info unless you build that info into the script which gets
> /var/www on a regular basis and commits it to subversion.
> What you really should do is let your developers work with Subversion
> and than checkout working copies of your software in /var/www, meaning that
> you should start in Subversion, not end there.
> > I will be grad if you can guide me there. My main misunderstanding is
> > that I don't know what happens
> > when you copy a new version of programs (same name dirs etc) to working
> > copy.
> > What shall I do for subversion to understand that these files have been
> > changed somehow.
> The svn clients detect themselves that files have changed, that not a
> problem. The real problem starts with renamed, deleted and moved files
> and directories because one, normally the developer, has to tell
> Subversion what moved where etc.
> Mit freundlichen Grüßen,
> Thorsten Schöning
Dr. Peter Kontopoulos
2, Parnassou St.
10561 Athens, GREECE
T: +30 210 3258 350 F: +30 210 3258 359
www.locotel.gr & www.locosms.gr
The information in this email is confidential and is intended solely for
the addressee(s). If you have received this transmission in error, and
you are not an intended recipient, be aware that any disclosure,
copying, distribution or use of this transmission or its contents is
prohibited. Furthermore, you are kindly requested to send us back the
original message at the address portmaster_at_locotel.gr, and delete the
message from your system immediately.
Internet communications are not secure and therefore LOCOTEL SA does not
accept legal responsibility for the contents of this message and for any
damage whatsoever that is caused by viruses being passed. Any views or
opinions presented are solely those of the author and do not necessarily
represent those of LOCOTEL SA.
Think Before you Print
Received on 2011-04-13 13:31:36 CEST