[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Best practices for getting non-tech folks to use subversion?

From: Mark Johnson <mj_at_sightworks.com>
Date: 2006-02-23 07:03:18 CET

I have been trying to deal with this scenario for the last year. The
problem for me is that most of the designers are on Mac, so there is no tool
available that can do what Tortoise can do. So I have them use DAV auto
versioning so they can use it in Golive etc. I then have a post-commit
script that performs an update of the working copy on the development vhost
server after each commit (I spawn a process using the '&' modifier so the
committer need not wait). So far this works quite well, but the biggest
hole is that DAV allows changes without the possibility of conflict, thus if
something gets overwritten, someone with tortoiseSVN has to merge the
changes from the previous revision. So really what I still need is either a
port of Tortoise to the Mac or a Subversion plugin for GoLive.

I too had thought of using a Samba mount to the working copy on the vhost
server, but it seems to me that having multiple developers directly access
the same working copy could result in non-recoverable overwrites (correct me
if I am mistaken)

I really hope that someday, designers and business folks will know the true
power of Tortoise and Subversion.

----- Original Message -----
From: "Christian Sauer" <christian@endrun.org>
To: "Philip Hallstrom" <subversion@philip.pjkh.com>
Cc: "Phillip Susi" <psusi@cfl.rr.com>; "Ryan Schmidt"
<subversion-2006Q1@ryandesign.com>; "Subversion List"
<users@subversion.tigris.org>
Sent: Wednesday, February 22, 2006 9:24 PM
Subject: Re: Best practices for getting non-tech folks to use subversion?

> On Wed, Feb 22, 2006 at 11:04:24PM -0600, Philip Hallstrom wrote:
>> >>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.
>>
>> The problem is that designers can't even see if things "look ok" without
>> putting the files on the vhost first. No way they will make a blind
>> change, commit it, test it, repeat. They just won't :)
>
> Bust isn't change-commit-test-repeat the same as their current
> change-ftp-test-repeat process? At my previous job where we rolled out
> version control to both developers and designers, they grumbled about
> being forced to use it and how "slow to their process" the
> change-commit-test-repeat was .... until they screwed something up and
> version control was able to roll back the changes in seconds instead of
> hours of recovering by hand. They stopped grumbling :-)
>
> The big thing I found having developers and designers working on web
> projects together was that designers weren't comfortable trying to merge
> in developer changes. We had to switch to a locking model.
>
>
> -Christian
>
> --
>
> They sicken of the calm, who know the storm.
>
> -Dorothy Parker
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 23 07:06:29 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.