[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: Jeremy Whitlock <jcscoobyrs_at_gmail.com>
Date: 2007-06-01 22:37:55 CEST

Excellent feedback. How do we handle these things? Do I need to
resubmit a new patch?

On 6/1/07, Eric Gillespie <epg@pretzelnet.org> wrote:
> "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:38:06 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.