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

Re: svn commit: r1422706 - in /subversion/trunk/subversion: libsvn_subr/opt.c tests/cmdline/svntest/main.py

From: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 18 Dec 2012 11:27:25 +0100

On Tue, Dec 18, 2012 at 12:19:02PM +0200, Daniel Shahaf wrote:
> Stefan Sperling wrote on Tue, Dec 18, 2012 at 11:03:56 +0100:
> > Why would you *not* want to do this? Don't say "because the bug isn't
> > in svn" since that is clear. We're not fixing a bug in 'svn'. We're
> > making it work properly by default in more environments.
>
> I didn't say you should not apply the patch --- I was just raising
> a point you seemed to have glossed on. You see that point and still
> think the patch is an improvement, so I don't have a reason you
> shouldn't apply the patch...

OK, thanks!
 
> > Or can you name a serious problem with this behaviour change?
> > I cannot think of one but perhaps I'm overlooking something.
>
> Well, since you ask, does it break
> echo p | svn up
> ?

That will postpone all conflicts since with my patch it's the same as
 svn up --non-interactive

And if it was interactive it would only answer one of possibly several
conflict prompts in the first place. You probably meant the equivalent of
 yes p | svn up

With the patch applied you can either use
 yes p | svn up --force-interactive
or, as usual,
 svn up --accept p
to postpone all conflicts. Or svn up --accept ':-P' of course.
Received on 2012-12-18 11:28:10 CET

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.