From what I have skimmed over, it appears that all your users need would be
TortoiseSVN which is very good for getting windows point-and-click fanatics
into the realm of source control.
IMO you should NOT try to hide the semantics of svn any more than that. In
order to use source control one *must* be acquainted with the concepts that
source control uses. Trying to hide that is ultimately broken and bound to
fail.
A better course would be installing TortoiseSVN for all of them and giving
them a basic run through of checkout, update, commit, merging / conflict
resolving, possibly creating a branch and switching to it, and if they feel
really brave, trying to merge their branch back to trunk. All of these
concepts, in my opinion, are the basis of source control, and if they arent
learned, the source control mechanism can not and will not be used
correctly.
On 2/27/07, Jared Hardy <jaredhardy@gmail.com> wrote:
>
> 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 05:13:15 2007