>> Find or write a CLI-GUI that wraps up the CLI tools into something that's a
>> little easier for someone used to a visual tool to use. I've looked and
>> haven't found a tool like this (searching for "text gui" doesn't help :-).
>> Does anyone know of one that exists? This is nice for me because again I
>> don't need to do anything special, and almost nice for them as at least it
>> would be simplified a bit.
>
> Sounds like you are looking for TortoiseSVN.
Yeah. Found that. It is slick :-)
>> Option 3 -
>>
>> Setup a VPN b/n the server and the designer and let them mount their
>> working-copy/virtual-server via Samba. They could then use TortiouseSVN to
>> manage commits. This is a lot more work for me and while initially
>> appealing for them, I wonder about how slow it would be for updates/commits
>> as it would be going round trip twice so to speak.
>>
>
> This is what I'd do. There also isn't a need for any kind of VPN mumbo jumbo
> either. Have the server auto checkout /released and /trunk from the
> repository, and serve those working copies as two different vhosts. That way
> the developers can commit changes to /trunk, and pull up the test vhost in
> their web browser to test, and then merge into released to push it live.
>
> Give them TortoiseSVN and show them how to use it, and they can access the
> server via https.
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 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.
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.
-philip
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 22 22:35:54 2006