You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Thorsten Schöning <ts...@am-soft.de> on 2011/04/13 11:34:42 UTC

Re:

Guten Tag Peter@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

-- 
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
 
Telefon: Potsdam: 0331-743881-0
E-Mail:  tschoening@am-soft.de
Web:     http://www.am-soft.de

AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow


Re: Updating the WC from an non svn directory

Posted by Ryan Schmidt <su...@ryandesign.com>.
On Apr 14, 2011, at 01:12, Peter@locotel wrote:

> Dear Ryan,
> thank u ever so much for your educated answer. I have to go through the material you
> sent me and apply to our development team. We have been using a backup like 
> procedure till today which has become unmanageable, as projects grow.
> 
> I hope that subversion will provide a traceable method for keeping our code.

Here are a few earlier responses I wrote on the subject:


Re: Want to set up SVN for a web app

http://svn.haxx.se/users/archive-2009-04/0083.shtml


Re: Two developers sharing one working copy on a LAN

http://svn.haxx.se/users/archive-2007-12/0142.shtml


Re: SVN and PHP

http://svn.haxx.se/users/archive-2007-07/0459.shtml


Re: SVN Files in Productionenvironments

http://svn.haxx.se/users/archive-2005-11/1004.shtml


There were also several responses when I first asked the question myself:

http://svn.haxx.se/users/archive-2004-12/0932.shtml




Re: Updating the WC from an non svn directory

Posted by "Peter@locotel" <pe...@locotel.gr>.
Dear Ryan,
thank u ever so much for your educated answer. I have to go through the
material you
sent me and apply to our development team. We have been using a backup
like 
procedure till today which has become unmanageable, as projects grow.

I hope that subversion will provide a traceable method for keeping our
code.

Keep up the good work
Peter
Στις 13-04-2011, ημέρα Τετ, και ώρα 15:52 -0500, ο/η Ryan Schmidt
έγραψε:

> On Apr 13, 2011, at 15:43, Ryan Schmidt wrote:
> 
> > you can do a search here:
> > 
> > http://svn.haxx.se/user/
> 
> Sorry, that should have been:
> 
> http://svn.haxx.se/users/
> 
> 



Re: Updating the WC from an non svn directory

Posted by Ryan Schmidt <su...@ryandesign.com>.
On Apr 13, 2011, at 15:43, Ryan Schmidt wrote:

> you can do a search here:
> 
> http://svn.haxx.se/user/

Sorry, that should have been:

http://svn.haxx.se/users/



Re: Updating the WC from an non svn directory

Posted by Ryan Schmidt <su...@ryandesign.com>.
On Apr 13, 2011, at 06:30, Peter@locotel wrote:

> The issue is that svn is not adapted to support web applications that live under
> web-servers.

Others have already replied, but I wanted to provide yet another affirmation that Subversion works great for web development -- I've been using it for years -- provided you use it properly, and not the way you've described. There are many, many threads in this mailing list's archives over the years that explain ways of using Subversion for web development; you can do a search here:

http://svn.haxx.se/user/

There is a FAQ entry that is relevant:

http://subversion.apache.org/faq.html#website-auto-update

There is a tool SVN::Notify::Mirror that is helpful for deploying web sites:

http://svn.haxx.se/users/archive-2006-02/1148.shtml

Also please read the Subversion book:

http://svnbook.org/

and allow yourself to be convinced that most of the methods described there are indeed applicable even to web development. Good luck.




Re: Updating the WC from an non svn directory

Posted by Andy Levy <an...@gmail.com>.
2011/4/13 Peter@locotel <pe...@locotel.gr>
>
> Thank u for your answer,
> I completely appreciate all your points referring to the proper use of subversion.
> The issue is that svn is not adapted to support web applications that live under
> web-servers.

It works perfectly fine for this, provided you use it properly.

>You have to export from repository to the web directory every so
> often to update the operational site (no checkin).

This is no different from any other version control system. You aren't
required to export, you can use a working copy and run svn update.

> Also web-applications can easily
> live, be developed and tested on developers workstations.

They should be. Developers should have a complete runtime environment
on their desktop for coding, testing & debugging before committing
code to the repository.

> 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 development management
> depending on individual preferences. It is another way of thinking about it.

It sounds like your issues are not with the software, but with your
developers' behavior and your process/workflow. If you enforce strong
access controls (random developers can't change code on the web
server) and a solid process for promoting code from the developer's
unit test environment up through production, Subversion works quite
well. If you leave everything wide open, or try to do things in a way
that's counter to Subversion's design, you will have trouble.

Re: Updating the WC from an non svn directory

Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Peter@locotel,
am Mittwoch, 13. April 2011 um 13:30 schrieben Sie:

> The issue is that svn is not adapted to support web applications that
> live under
> web-servers.

You can use it pretty fine this way, I do for Perl web applications
processed by Apache HTTPD, Java web applications under Tomcat etc.

> You have to export from repository to the web directory
> every so 
> often to update the operational site (no checkin).

You don't have to, the web applications in productional state are just
tags in the repository and checked out as normal working copies
directly in /var/www/whatever. Development is merged to the those tags
whenever you think it's finde to do so and you just have to issue an
svn update on the working copy on the server.

> Also web-applications
> can easily
> live, be developed and tested on developers workstations.

That's what trunk and/or branches are for, depending on the
development model you prefer.

> 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.

Depends on their debugging and what is needed. Do they really need to
delete whole directories this often?

> So I
> had to resort
> to a way of managing revisions centrally and allow for a loose
> development management
> depending on individual preferences.

Subversion will be of no use in this case or what are the features
Subversion provides you will want to use? The logs won't be meaningful
to you because whoever commits won't know all changes. Every commit
will be huge and hard to look for errors etc. I don't think it's worth
the time.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
 
Telefon: Potsdam: 0331-743881-0
E-Mail:  tschoening@am-soft.de
Web:     http://www.am-soft.de

AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow


Re: Updating the WC from an non svn directory

Posted by "Peter@locotel" <pe...@locotel.gr>.
Thank u for your answer,
I completely appreciate all your points referring to the proper use of
subversion.
The issue is that svn is not adapted to support web applications that
live under
web-servers. You have to export from repository to the web directory
every so 
often to update the operational site (no checkin). Also web-applications
can easily
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
development management
depending on individual preferences. It is another way of thinking about
it.
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@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
CTO

LOCOTEL SA
2, Parnassou St.
10561 Athens, GREECE
T: +30 210 3258 350 F: +30 210 3258 359
www.locotel.gr  &  www.locosms.gr 
________________________________________________________________________

Email Disclaimer
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@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. 
Thank you,
LOCOTEL SA
Think Before you Print