On 2/21/07, Bolstridge, Andrew <andy.bolstridge@intergraph.com> wrote:
>
>
>
> Please take your unhelpful comments and shove them.... users are users, we
> must learn to make our products suit them, not make them to suit ourselves
> and then tell the users they are stupid. already.
I agree he was a little harsh, but there's a valid point in there. At
some point, the user has to accept responsibility for knowing how to
use the tools required to do their job. There has to be a middle
ground - if the tools are simplified so far as to allow anyone who can
operate a mouse and keyboard to do the job, they'll lose their utility
to the people who were the original intended audience. Make it too
complex and no one will use it.
I wouldn't let my brother help me remodel a room in my house without
making sure he knows how to use a drill & saw. I don't expect him to
know *how* the drill & saw work, but he at least needs to know how to
operate them. That's where the OP's clients are - they need to at
least wrap their heads around the basics of how to use version control
software (not just Subversion, he'd have the same problem with any
other tool).
> My suggestion for the mac webdev shop is to forget about using the command
> line stuff, to install the webdav server protocol and allow the users to use
> that instead. I do not know how that helps you with moving files around the
> repository (I imagine it doesn't delete the old one) but it may be a start.
> We have started using the webdav access method as it is the only way to get
> at individual files (we have users that don't use svn in the way it was
> designed to be used either) and it is working very well so far.
The OP has already indicated that he looked at WebDAV/Autoversioning
and it doesn't meet his needs.
>
> -----Original Message-----
> From: Matt Sickler [mailto:crazyfordynamite@gmail.com]
> Sent: Tue 20/02/2007 20:45
> To: Les Mikesell
> Cc: Mark Lundquist; users@subversion.tigris.org
> Subject: Re: Crazy idea? Remote SVN client for the Subversion-impaired
>
> your best (and probably easiest in the long run) is to have the devs read
> The Subversion Book and learn svn already
>
> trying to mask the versioning from the developer is stupid
>
> me to them: LEARN THE FSKING SHELL ALREADY - MAC AINT WINDOWS!
>
>
> On 2/20/07, Les Mikesell <lesmikesell@gmail.com> wrote:
> >
> > 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
> >
> >
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 21 13:40:00 2007