Hi All,
Attached is revision three of the patch for issue 2784, automatic
conflict resolution. You should notice the proper verbiage being used
in the patch and that the changes Eric suggested last have been taken
into account during this new version of the 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
"resolved" 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 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
automatic conflict resolution 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/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.
(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/10/07, Jeremy Whitlock <jcscoobyrs@gmail.com> wrote:
> Karl,
> I agree and I usually don't hesitate but there has been some
> disagreement both ways and I wanted to see if there was someone other
> than Eric and myself that could put the nail in the coffin so we could
> put this to rest.
>
> Take care,
>
> Jeremy
>
> On 6/10/07, Karl Fogel <kfogel@red-bean.com> wrote:
> > "Jeremy Whitlock" <jcscoobyrs@gmail.com> writes:
> > > I can do whatever *we* decide is right. I think accepting them
> > > all makes sense since the verbiage can be misleading if you do not.
> > > Can someone else agree with this approach so I can resubmit a new
> > > patch?
> >
> > I agree.
> >
> > But you don't have to wait for someone else to agree to submit a new
> > patch -- if you're pretty sure agreement is likely, you can just post
> > the revised patch and wait for someone to disagree with the approach :-).
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 12 10:43:39 2007