[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-05 07:38:18 CEST

Hello All,
    Attached is revision 2 of the patch to add automatic conflict
resolution to the resolved command as part of issue 2784. All of
Eric's suggestions have been implemented:

Removed all noticed trailing spaces
Made the --accept flag a long-only flag
Updated the verbiage in the help output and source to match the
acceptable accept flag options
Removed unnecessary/unused code
Refactored for the removal of the unnecessary code

The commit log message for the suggested patch is below, and should be
more inline with the submission process. Thanks for all who have
helped and feel free to request another revision of this patch.

Take care,


Add option to resolve conflicts by selecting a specific file by adding
support to the svn executable to handle the "--accept" flag. The
"resovled" subcommand is the only subcommand using this new flag as
part of this patch. (Issue 2784)

* subversion/include/svn_client.h
  (svn_client_resolved): Revved to svn_client_resolved2() to handle
  the svn_accept_t enum.

* subversion/include/svn_types.h
  (svn_accept_t): Created an enum to handle the different accept options.
  (svn_accept_from_word): Function prototype to return the proper
  svn_accept_t based on the accept word.

* subversion/include/svn_wc.h
  (svn_wc_resolved_conflict): Revved to svn_wc_resolved_conflict3 to
  handle the svn_accept_t enum.

* subversion/libsvn_client/resolved.c
  (svn_client_resolved): Implementation of svn_client_resolved2()
  which now handles the svn_accept_t as an argument.

* subversion/libsvn_subr/kitchensink.c
  (svn_accept_from_word): Implementation of svn_accept_from_word()
  which will return an svn_accept_t based on the passed accept string.

* subversion/libsvn_wc/adm_ops.c
  (resolve_conflict_on_entry): Updated this function to handle an
  svn_accept_t argument. This is also where the real work of handling
  the accept flag happens.
  (resolve_callback_baton): Updated the structure to have a
  placeholder for the svn_accept_t argument so that
  resolve_found_entry_callback() can pass the necessary information to
  (svn_wc_resolved_conflict): Implementation of
  svn_wc_resolved_conflict3() which now handles the svn_accept_t as
  an argument.

* subversion/svn/cl.h
  (svn_cl__opt_state_t): Updated to have a place holder for the accept
  flag passed to the svn executable.
  (svn_cl__long_opt_t): Updated to handle the svn_accept_t as a long
  svn executable argument.

* subversion/svn/main.c
  (svn_cl__options): Updated to have all necessary information for the
  svn executable to provide help for, and handle, the accept flag in
  both long and short format.
  (svn_cl__cmd_table): Updated to have the resolved subcommand handle
  the passing of the accept flag.
  (svn_cl__limit_opt): Added case statement to handle parsing the
  accept flag and erroring when an invalid argument was passed. If a
  valid argument is passed, it is then turned into the svn_accept_t enum
  based on the svn_accept_from_word() function in

* subversion/svn/resolved-cmd.c
  (svn_cl__resolved): Updated to call the revved svn_client_resolved()
  which is now at svn_client_resolved2().

* subversion/tests/cmdline/basic_test.py
  (automatic_conflict_resolution): Created a new test to test the
  handling of the new accept flag for the resolved subcommand.
  (test_list): Added the automatic_conflict_resolution test to the test list.

On 6/1/07, Jeremy Whitlock <jcscoobyrs@gmail.com> wrote:
> Hi All,
> I will come out with a new patch that takes care of the things
> brought up by Eric. Please feel free to make other suggestions as
> well.
> Take care,
> Jeremy
> On 6/1/07, Karl Fogel <kfogel@red-bean.com> wrote:
> > "Jeremy Whitlock" <jcscoobyrs@gmail.com> writes:
> > > Excellent feedback. How do we handle these things? Do I need to
> > > resubmit a new patch?
> >
> > That's the usual way. It's normal for a patch to go through many
> > rounds of review/modify before being accepted into the code base,
> > don't worry.
> >

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Received on Tue Jun 5 07:38:30 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.