Mark Lundquist wrote:
> I have a situation with one of my clients that seems to call for a novel
> solution.
I think the 'crazy' in the subject is appropriate here.
> 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.
> All the web application assets are controlled under Subversion. I set
> up Subversion for them and taught the more technically-inclined of this
> crew how to do basic things like committing from a "development" working
> copy, updating to a "production" working copy, "svn add" (and a few
> other things... but those three are really what he ends up being able to
> reliably do). Incidentally, this guy is the only one of the bunch who
> has any clue what to do with a Unix shell. The other one does HTML
> content updates, and she is completely hopeless when it comes to the
> command line. These are People Of The GUI, and I'm not going to be able
> to change them.
If they want a gui, give them a GUI. Have they tried eclipse/subeclipse?
> Sometimes they need to delete/copy/move/rename things (including
> directory structures). When the less-skilled of the two needs to do
> this -- and I suspect the other one too, sometimes -- they just blunder
> on ahead using the Mac Finder (GUI file manager), resulting of course in
> a total pooch-screw of Subversion at working copy level.
Working copies should be disposable. A fresh checkout should fix any
working copy problem.
> Now, you might say "Just get them a nice GUI Subversion client to use,
> like SVNx for Mac OS X". Only one problem — they don't use *local* svn
> working copies. The working copies are all on a server, and they mount
> the server fs as an AFP share so they can edit (and also use the
> accursed Finder) from their own workstations. And actually, it really
> has to be that way, for a couple of reasons:
Mounted filesystems should be transparent to a subversion client. Why
would this make any difference?
> 1) These aren't static web-sites, they're served by a Java servlet
> framework. So you can't just pull up a page source file in a browser,
> you have to be running the servlet application for any of it to work.
If you have multiple people making changes they probably need their own
(at least virtual) web server to view/test them.
> Setting these up and starting/stopping them is child's play for someone
> with the right skill set (and this is how I work on their projects -- I
> have all my own local working copies on my laptop and run the web
> applications here), but it's really beyond what these other peeps can
> handle, bless their hearts :-).
Give them a button that ssh's the appropriate restart command to their
viewing server if it isn't on their own machine.
> It also has to be on a server so that
> when things break, I can access it to witness/debug/fix the problem. If
> they were running these on their own machines, they might as well be on
> the far side of the Moon.
If they break their working copy, tell them to check out a new one.
> 2) Same goes w.r.t. to Subversion; when they inevitably botch up their
> working areas, at least its on a server that I can log in to, so I can
> go clean up the mess.
>
> You might also say "maybe you should use a real web-based
> content-management system for this kind of thing, instead of a
> Subversion repository". But notice that since I have just said, "you
> might also say...", nobody need now actually say that... :-)
If you are using a subversion repository, it should be a working copy
that is only updated, never edited directly, or an rsync or similar copy
of such a working copy. And especially don't let anyone use direct
filesystem access to this one. Give them a button that ssh's an
update command wherever this WC lives and then does whatever else it
takes to make the web server notice.
> So then...
> DESIDERATA
> ----------
>
> Suppose there were Subversion client that ran as a server daemon
> implementing WebDAV or SMB or NFS or AFP. Its purpose would be to Do
> The Right Thing when asked to delete/copy/move/rename elements that are
> already under Subversion control. 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. This would just allow somebody who is
> Subversion-blissfully-unaware (and completely command-line-incapable) to
> mount a remote Subversion working area and do naive filesystem
> manipulations using their GUI of choice, without totally botching up the
> working copy metadata.
What's the point of using a dumb GUI and trying to build a
smart-enough-filesystem to second guess its mistakes when smart GUI's
already exist?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 20 21:12:48 2007