On 15/06/2008, at 3:05 AM, Karl Fogel wrote:
>> To start I've modified the log_msg_func callback to accept a new
>> argument that will be an array of paths representing unversioned
>> items. I've added the necessary logic in libsvn_client and updated
>> command line client's svn_cl__get_log_message so it accepts the list
>> of unversioned items and prints them in the log message.
>> If all that looks O.K. then my next step would be to extend the
>> harvest_committables function so it can find any unversioned
>> files. Then once that works, add the necessary logic into the library
>> to filter out all the items that have been set to be ignored. The
>> I can't work out at the moment is *how* to find the unversioned
>> items. When first looking through this I thought it should be easy to
>> borrow that logic from the status command (including filtering
>> ignores) but on closer inspection it looks like status and commit
>> quite differently. Hints on where to look would be appreciated.
> I think I know what the problem is: harvest_committables() is guided
> strictly by the entries lists -- that is, it only ever hears about
> that are under version control, or are formally marked for addition
> version control. It's probably never even told about unversioned
> (A cursory look over the code seems to confirm this.)
> Now, this could be changed. Changing it would affect the
> performance of
> harvest_committables(), since it would now have to look at the
> on disk as well as at the svn entries list. Therefore, you'd probably
> want to pass a boolean flag indicating whether or not to discover
> unversioned items.
> Does that make sense?
Yes that's what I thought was going on. I'll continuing working in that
direction. I'll have to come up with some configuration item and/or
command line flay to control the boolean flag I suppose.
> Some patch review below...
>> Working towards issue #3217: svn commit should show unknown files
>> in editor
>> Modify the log message callback to use the newly created
>> svn_client_get_commit_log4_t type. The new callback type
>> includes a list of unversioned items that are in the
>> working copy that we can now include in the log message
>> when calling and external editor.
>> * subversion/svn/cl.h
>> (svn_cl__get_log_message): Add parameter unversioned_items so
>> it is now compatible with svn_client_get_commit_log4_t.
>> * subversion/svn/util.c
>> (svn_cl__get_log_message): Modify this callback to be of the
>> new svn_client_get_commit_log4_t type. When calling an external
>> editor add the list of unversioned_items after the commit_items.
>> * subversion/svn/main.c
>> (main): assign svn_cl__get_log_message to log_msg_func4 rather
>> than log_msg_func3.
>> * subversion/svn/move-cmd.c
>> Replace use of log_msg_func3 and log_msg_baton3 with the
>> new log_msg_func4 and log_msg_baton4.
> Er, but there is no 'svn_client_get_commit_log4_t' type... At
> least, not
> in this patch, and not on trunk.
There were two patches attached. libsvn_client-unversioned-log.diff has
the relevant changes to the library code. The patch you've review
only the changes to the svn client.
> Similarly, neither the log message nor the patch shows
> log_msg_func4 or
> its baton being declared as new structure fields where I'd expect
> You don't need that final "*" item; you can just note that all callers
> were updated at the log entry for the new type.
I've updated both patches and the log messages to include your
The only way I can work out to get a suitable MIME type is to send as
file (I using Mail.app if anyone knows how to make it work...) Hope that
is O.K. (make check passes with both patches applied to trunk)
Received on 2008-06-15 14:36:25 CEST
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org