"Wadsworth, Eric (Contractor)" <wadswore@fhu.disa.mil> writes:
> > I'm not sure this is a big enough problem to warrant any special
> > support. Honestly, in ~8 years of working with copy-modify-merge
> > revision control systems (CVS and then Subversion), I think I've maybe
> > lost a total of 30 minutes to this sort of semantic problem. Usually
> > I knew in advance (from commit mails or other forms of developer
> > communication) that the incoming change was dangerous, and adjusted my
> > update accordingly.
> >
> > If your user has had a different experience, that's one thing. But if
> > she's just *anticipating* a problem, then I want to say "Try it and
> > you'll see."
>
> I'm totally in agreement with you. I have no problem with the current
> functionality. But I'm trying to rally support for subversion from the
> development team. "Try it and you'll see" almost works, but better would be
> "Oh, if you're worried, just do a 'svn up --paranoid' and it will make a
> copy of each of your pre-merged files before doing its automatic merge." We
> could change --paranoid to --unreasonably_paranoid just to make it clear...
> ;)
Or put on your Carl Sagan voice: "*billions* of users have been using
CVS for years, and have had no problems with this..."
Seriously, your scenario reminds me of the kind of PHB reactions I
sometimes see when trying to explain concurrent versioning -- "what?
no locking? it will never work!". These days, I just point them to
the beginning of chapter 2 in the svnbook.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 18 17:44:57 2003