On Feb 22, 2006, at 22:43, Phillip Susi wrote:
> Philip Hallstrom wrote:
>> Hmmm. If I read what you're saying right, you mean setup a post-
>> commit hook (or whatever it's called) to automatically check out
>> any commits made to the vhost, right? The problem I see with that
>> is the designers
>
> You could do that, or have a cron job do an svn update every 5 mins
> or something.
>
>> would have to commit all their changes even when just playing
>> around with something which could get tedious for them. I'd
>> prefer it if they could muck around for a bit, get things the way
>> they want them, then commit.
>
> They can muck around all they like in their working copy before
> they decide to commit. How does that differ from mucking around
> then uploading via ftp?
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.
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).
>> Good point on the https. For some reason I thought my choices
>> were http, svn or svn+ssh. Thanks!
>>> I'm no sure what you mean by round trip twice. Small updates and
>>> commits should be plenty quick.
>> In the case where we have a dev server with the vhost and working
>> repository. We use Samba so the user can mount the vhost on their
>> desktop. We use TortioseSVN for subversion. When the user tells
>> Tortiose to update the working copy, it will communicate with the
>> subversion server, downloading any files that need updating and
>> then copying them to the samba share. Tortiose thinks it's local,
>> but it's really copying them down only to copy them back again.
>
> If you are going to use svn then there is no need for samba; do
> away with it. Users can use their local hard drive to hold their
> working copy.
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.
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.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 23 02:30:08 2006