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,
Jeremy
[[[
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
resolve_conflict_on_entry().
(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/libsvn_subr/kitchensink.c.
* 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