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

Re: [PATCH] Add option to resolve conflicts by selecting a specific file (Issue 2784)

From: Eric Gillespie <epg_at_pretzelnet.org>
Date: 2007-06-01 22:11:55 CEST

"Jeremy Whitlock" <jcscoobyrs@gmail.com> writes:

> Trailing white space: Yeah. That is a good ol' Eclipse feature...I'll
> remember this next time.

Well, i don't think anyone but me cares.

> svn_accept_unknown being redundant: It isn't. I use it for a few
> checks throughout the code. If you come into through the command
> line, this is handled automatically but if you use the libraries, I
> thought it would be safe to check for it. If not, feel free to remove
> upon patching.

In resolve_conflict_on_entry, test svn_accept_merged instead of
unknown or empty. Ah, svn_accept_from_word would need to return
svn_accept_unknown when it's passed a bogus value.
svn_cl__resolved need not see it, though.

So, the only two places that should deal with svn_accept_unknown
are svn_accept_from_word and any caller thereof.

> Negative values: I used the --depth flag as an example. Maybe I
> should had done something different.

Huh. That looks odd, too. Well, whatever :).

> Code left over from a previous attempt: Not sure. I revved the
> function as requested.

Requested by whom? I remember you mentioned revving this at one
point, and i said this function had no business knowing about
this, and that there should be a baton you could use instead. I
see that you did take the baton approach, and your revved
function isn't referenced anywhere at all.

> svn_accept_to_word never used: I followed the --depth flag handling
> for this as well. I planned on using but I guess it was never
> required.

That one's used, though.

Eric Gillespie <*> epg@pretzelnet.org
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 1 22:12:05 2007

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.