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

Re: Locking consensus(es) so far

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2004-10-14 16:34:25 CEST

Ben Collins-Sussman <sussman@red-bean.com> writes:

> I'm suggesting that the UI be something like this:
> $ svn update hijacked-file.c
> WARNING: you have changed this file without locking it, which is bad!
> WARNING: a newer version of the file has been saved in
> 'hijacked-file-backup.c'
> WARNING: please examine the newer file before committing your own
> changes!

You can do that with a wrapper round svn, there is no need to change
the core code.

I haven't been following this discussion, but I think you are
restricting this to files with svn:lock set. If one accepts that this
behaviour is desirable (I don't) should it not apply to all files?
How does your hypothetical user handle conflicts in files that don't
have svn:lock set?

  use-current-to-resolve-conflicts = yes

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 14 16:44:57 2004

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.