On 2/20/07, Mark Lundquist <lundquist.mark@gmail.com> wrote:
> One of my clients is a tiny Web design/development/hosting company that
> maintains a bunch of web sites/applications for their customers. They
> do content and graphic design, while I am in charge of all the geekery.
I thought I would chime in, because I am in a similar situation. My
users here are pretty savvy, but over half of them are 3D artists of
some sort, who would just rather not deal with working outside the
native GUI file browser for any basic file operations. We have been
using TortoiseSVN successfully in Windows, but I still get complaints
about wedged Working Copy problems, almost daily.
> Suppose there were Subversion client that ran as a server daemon
> implementing WebDAV or SMB or NFS or AFP.
As others have mentioned, Subversion already has you covered here with
WebDAV. From my own experience, I would say putting Subversion Working
Copies on network shares is a very bad idea, *especially* with users
who aren't careful or communicative. Using WebDAV with Autoversioning
on the main repository would be your best bet... just not for most
process considerations.
How I suggest using WebDAV Autoversioning capability may end up
being very controversial, and difficult to set up... but possibly very
rewarding. I say you should set up Subversion 1.4.2+, SVK 2.0+, and
Apache 2.2+ on each client. SVK Mirror the repository holding your
content tree, or possibly just the folder/branch the user is
interested in. Make a local copy of the mirror branch using "svk cp
...". Set up local Apache with local access to the SVK-Subversion
repository, with Autoversioning on. Then use whatever WebDAV FS
mounter your system provides, to map the local Subversion/WebDAV
folder of interest to a local working folder. After that, the user can
manipulate the local copy as if it were a regular folder, in their GUI
of choice, without affecting the central source repository until
"Commit".
All that remains is giving users access to "Update" and "Commit"
equivalent scripts, which would map to "svk pull ..." and "svk push -l
..." commands in the background. In Windows File Explorer, I set up
"Send To" menu shortcuts to these scripts, so that any path(s)
selected in File Explorer would be passed as arguments to these
scripts, when the shortcuts are selected, from the "Send To" R-click
context menu. I don't know what the Mac Finder equivalent to the "Send
To" context menu is.
> Somebody would still have to go "under the covers" in order to svn
> add/commit/update/merge/etc., but I am already doing that anyway.
SVK would handle all this in the background, whenever your user
initiates an "Update" or "Commit" script. The "svk push -l ..."
command would push all the changes as an atomic commit, back to the
SVK Mirrored source repository. You might want to create a GUI to
allow the user a chance to enter commit log messages, since "svk push"
doesn't provide this by default. You may also want to set up SVK so
that it pops up the Merge tool of choice whenever an "Update" hits a
Conflict. Your users will have to be familiar with the merge tool, and
what to do when it appears. Otherwise you'll have to set up some
custom locking system, using lock tokens on the central Subversion
repository as your semaphores.
You may want to give each user their own branch copy on the source
repository, that gets automatically merged from trunk periodically.
That would allow you to set up a verification process before changes
get back to trunk. The verification step may start out as a manual
merge process, but you should be able to automate it eventually. That
verification step would also prevent polluting other user's working
copies with bad changes.
Otherwise, I think to get what you want, you will have to write
your own lib_svn_wc library, or your own Subversion Browser GUI,
sufficiently similar to Mac Finder. While the SVN/SVK/Apache/WebDAV
setup may seem complicated, it may be easier than coding your own
WC/Browser-GUI from scratch.
:) Jared
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 28 02:07:41 2007