Mark Lundquist wrote:
>>
>> 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.
If you have made changes worth saving they are worth committing. Lots of
bad things can happen to your working copy with or without your own
mistakes. There is an easy way to protect your work.
> You're right, working areas are disposable — to Subversion, but not
> necessarily to people.
The changes since your last commit should be disposable or you should
arrange some other kind of backup.
>>> 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
Huh? Who cares about the timestamps and why would they be different on
a network mount?
> 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.
Network filesystem speed is a solvable problem - probably mostly fixable
with sufficient ram on the server. But that's probably not the way you
should go anyway.
>> 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.
*This* is the problem you need to solve. I don't think you will get
much sympathy here about problems with a shared working copy.
Subversion wasn't designed for that.
> 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!
If you had committed those changes, no problem.
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 send your kid out to play in the street and he gets hit by a bus,
what else can they do?
>> 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.
Yes, if they are incapable of doing 'svn add' for new files, you'll have
to find something to help them with that. But you don't have to let
them screw up the place where anyone else works.
>> > 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.
If you can't solve the problem you want, change the problem. Check out
a copy for each user and either teach them to run "svn commit" and "svn
update" or hook an icon to those commands for them. That fixes your
network mount speed problem and keeps a simple mouse drag from breaking
everyone's work. Then you can get back to finding a GUI they can use.
> 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.
Svn needs to know about adds, moves, copies. A GUI that manipulates
files under svn's control without notifying svn isn't designed for the
work you want it to do.
> 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.
Or use a more sensible setting where you do local work locally and let
svn take care of combining it with the work others do *and* making sure
you can get a fresh copy or back out to any prior version.
--
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 Thu Feb 22 03:57:59 2007