Les Mikesell wrote:
> Mark Lundquist wrote:
>> [...]
>
> If they want a gui, give them a GUI.
Brilliant, now why didn't I think of that? Oh wait... I did. See below.
> Have they tried eclipse/subeclipse?
Of all the Subversion GUIs, Eclipse+Subclipse (a software development
tool) would probably be the worst for these users (who are not software
developers). SNVx would be a better choice if it were just about
picking the most suitable GUI Subversion client, but it's not... none of
these tools will work in this situation, for reasons that I went to some
trouble to explain.
>
> Working copies should be disposable. A fresh checkout should fix any
> working copy problem.
Yeah, except it seems to me that when you just delete a working area,
there's *something* that can be lost... now, what was it? Ah, now I
remember, something about LOCAL MODIFICATIONS.
You're right, working areas are disposable to Subversion, but not
necessarily to people.
>> 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?
Two reasons:
1) timestamps
2) performance
I could be wrong about (1), not sure... (2) is definitely an issue with
SVNx. It looks like it has to stat a crapload of files, and it's
glacially slow over AFP.
I've been scouting around for other OS X Subversion GUIs, maybe I'll
find one that's quicker in this setting.
Actually, what has me more worried is the feeling that there is a (3)
that's I'm forgetting about...
>
> If you have multiple people making changes they probably need their own
> (at least virtual) web server to view/test them.
Actually no, they do not need that. They've been using this work style,
with a shared development area, for a couple of years, and it hasn't
been a problem. Their work naturally does not overlap very much, and
they coordinate pretty well to keep from stepping on each others' toes
when it does. The problem is that the know-how to keep from stepping on
Subversion's toes is really beyond their reach.
Even if they had their own work areas, it wouldn't solve this problem,
in fact it would magnify it. So this is irrelevant.
>
> Give them a button that ssh's the appropriate restart command to their
> viewing server if it isn't on their own machine.
No; nothing needs to be restarted when they make their changes. It's
not about that. This doesn't help me, even if I did have time to spend
"making buttons", which I do not.
>
> If they break their working copy, tell them to check out a new one.
It's not *their* working copy, it's *the* shared development area which
comes to them "ex nihilo" (i.e., I set it up for them). They do not
know about the repository or how to "check out" things.
But anyway that's a moot point see above, "just delete it and check
out a fresh one" is *not* the solution for a hosed working copy with
local changes! It's like if the hospital said "Thank you for bringing
your child to the emergency room today. We've found that rather than
treating certain cases, it's much easier to just provide you with a
replacement child."
> If you are using a subversion repository, it should be a working copy
> that is only updated, never edited directly,
Well, that's certainly true for the "production" instance, certainly not
true for the shared "development" instance, and this tangent about
shared vs. individual areas is irrelevant. The issue is just "dumb file
manager GUI vs. Subversion"; it doesn't matter whether there are 1 or 10
people using the working copy.
> > 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?
The point is that the "smart GUIs" all operate on local working copies,
and I believe that prevents me from using them to solve this problem.
Maybe I'm wrong about that.
Characterizing the dumb GUI as making "mistakes" that need to be
"second-guessed" is unproductive. They aren't "mistakes" at all; it's
just a case of a tool doing what it is designed to do and nothing more.
A solution to this problem using a "dumb GUI" is actually easier to
accomplish in principle than one that uses a "smart GUI". In order to
use the "smart GUI" in this setting, one would have to (a) invent some
kind of "Subversion remote working copy protocol", then (b) write a
server to implement it, and (c) teach the smart GUIs how to use this
novel protocol. The solution I had in mind would use one of a number of
available "dumb" protocols that already exist, and for which a number of
"dumb GUI" clients also already exist. All that would need to be done
would be to write the server part. I was just curious to find out if
anyone had done anything like that.
ml
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 22 01:48:17 2007