[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Disabling automatic conflict resolution?

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-08-18 17:40:12 CEST

"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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.