Ryan Schmidt wrote:
>
> I think Philip was describing a process by which uploading via FTP is
> part of the testing phase. Changes are made locally, then uploaded to
> the (presumably development or staging) server to be tested, and once
> everything has been done and tests correctly, then the code is
> presumably uploaded to the production server for deployment.
>
Exactly. Instead of uploading to the staging server with ftp or samba,
you just commit to the svn development branch to test, then instead of
uploading to the production server with ftp or samba you merge from the
development branch to the production branch.
> Using Subversion, as you say, you commit once your code is done and
> tested. But in this scenario it cannot be tested until the code is on a
> server; it cannot be tested locally (see below).
>
>
No, you commit to the development branch once you are satisfied that
your changes look ok and it is time to test. Then you test by pulling
up the testing vhost on the server in your browser.
> This presumes that the users have a complete local environment they can
> use to test the system before they commit. For web site design,
> especially dynamic web sites, especially database-driven ones, this is
> not necessarily a reasonable assumption, especially in the case of
> people like designers who shouldn't have to concern themselves with the
> intricacies of setting up and keeping up-to-date an Apache, PHP and
> MySQL installation, or whatever the languages and systems are that are
> being used.
>
See above.
> In our web design company, we have one central development server which
> not only serves as Subversion repository server but also as Samba
> server, web server and MySQL server. Our developers create their working
> copies in their public_html folder in their home directory on the
> development server, not locally on their own drives. This way, they can
> use the central web and database servers that I and our other sysadmin
> maintain, and they can still use their local text editor by editing
> files on the Samba share, and using TortoiseSVN to commit when done with
> a task.
>
There is no need for the home directory on the server. They can use
their favorite local text editor on a local working copy, then commit to
the development branch when they are ready to see how the code runs on
the server.
>
>
> To the original question: the best way to get non-technical folks to use
> Subversion is to get them to use Subversion the way it was intended to
> be used. Yes, it's a change; yes, they'll have to learn new things and
> do things differently. But a version control system is a complex system,
> and it doesn't just run itself. It needs to be used properly in order
> for it to be fully useful. For example, if you use WebDAV, there are no
> commit messages (as a WebDAV client would never prompt for one, as a
> WebDAV client would never know that it's communicating with a Subversion
> repository and not any other kind of WebDAV server). Without commit
> messages, you cannot ever know *why* someone made a change, and in the
> case of binary files where you can't run diffs, you can't easily
> determine *what* was changed without opening both versions of the file
> side by side and hoping you can visually spot the change. By teaching
> your users to use Subversion the right way, writing meaningful commit
> messages, keeping separate tasks in separate commits and all the parts
> of one task in a single commit, and so forth, you get a system that
> works the way it was meant to, and can help you answer questions later.
>
>
Exactly.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 23 05:48:12 2006