You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2004/05/03 15:19:06 UTC
Re: svn commit: r9592 - trunk/subversion/libsvn_client
On Sat, 2004-05-01 at 09:33, jpieper@tigris.org wrote:
> Author: jpieper
> Date: Sat May 1 09:33:16 2004
> New Revision: 9592
>
> Modified:
> trunk/subversion/libsvn_client/blame.c
> trunk/subversion/libsvn_client/client.h
> trunk/subversion/libsvn_client/ra.c
> Log:
> Issue #1093: Update svn_client__prev_log_path to work with the current
> blame routine and refactor the existing blame code to use it.
Man, I am so happy you're working on this. :-)
> Modified: trunk/subversion/libsvn_client/client.h
> ==============================================================================
> --- trunk/subversion/libsvn_client/client.h (original)
> +++ trunk/subversion/libsvn_client/client.h Sat May 1 09:33:16 2004
> @@ -98,6 +98,8 @@
> particular resource has undergone when performing an RA->get_logs()
> operation on that resource. */
> svn_error_t *svn_client__prev_log_path (const char **prev_path_p,
> + char *action_p,
> + svn_revnum_t *copyfrom_rev_p,
> apr_hash_t *changed_paths,
> const char *path,
> svn_node_kind_t kind,
Would you mind documenting the two new variables?
Also, I have a meta-worry:
If you read the log history for blame.c, there have been some bugfixes
to its core logic, but these happened *after* cmpilato branched the code
into his svn_client__prev_log_path() patch. I can't remember the
details of the fixes, but I'm concerned that blame.c has now regressed:
it's now using factorized code, but the factorized code is lacking the
bugfixes.
So that's the next step: can you do a bit of research, and make sure
svn_client__prev_log_path is just as robust as the blame code you just
deleted?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r9592 - trunk/subversion/libsvn_client
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mon, 2004-05-03 at 10:50, Josh Pieper wrote:
> I did do that research, and adding those two extra parameters was the
> only thing I could find that affected prev_log_path. The only big
> bugfix between November and now to log_message_receiver was in part
> helped by cmpilato, and seemed to be included in prev_log_path
> already.
Huh, ok. Maybe cmpilato and I were exaggerating our memory of the
bugfixes applied to blame. If you've audited them already, then that's
great.
As a next step, can you make 'svn ls -rN wcpath' and 'svn checkout -rN
wcpath' follow copy history? They should behave just like 'svn cat -rN
wcpath' (svn_client_cat is the current model):
* if a wcpath is passed in, call svn_client__repos_locations.
* if a URL is passed in, just use it directly.
It would be nice to see a couple new, simple regression tests too,
similar to basic_tests.py #25.
Once that's done, then I think we'll be ready to get to the Main Meat:
figuring out how to make svn_client_diff and svn_client_merge use the
new repos_location function. This will be a bit trickier, I'm guessing,
because we have to deal with some UI issues.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r9592 - trunk/subversion/libsvn_client
Posted by Josh Pieper <jp...@andrew.cmu.edu>.
Ben Collins-Sussman wrote:
> On Sat, 2004-05-01 at 09:33, jpieper@tigris.org wrote:
> > Modified: trunk/subversion/libsvn_client/client.h
> > ==============================================================================
> > --- trunk/subversion/libsvn_client/client.h (original)
> > +++ trunk/subversion/libsvn_client/client.h Sat May 1 09:33:16 2004
> > @@ -98,6 +98,8 @@
> > particular resource has undergone when performing an RA->get_logs()
> > operation on that resource. */
> > svn_error_t *svn_client__prev_log_path (const char **prev_path_p,
> > + char *action_p,
> > + svn_revnum_t *copyfrom_rev_p,
> > apr_hash_t *changed_paths,
> > const char *path,
> > svn_node_kind_t kind,
>
> Would you mind documenting the two new variables?
Of course, I meant to do that, but the desire got misplaced in between
switching to the header file.
> Also, I have a meta-worry:
>
> If you read the log history for blame.c, there have been some bugfixes
> to its core logic, but these happened *after* cmpilato branched the code
> into his svn_client__prev_log_path() patch. I can't remember the
> details of the fixes, but I'm concerned that blame.c has now regressed:
> it's now using factorized code, but the factorized code is lacking the
> bugfixes.
>
> So that's the next step: can you do a bit of research, and make sure
> svn_client__prev_log_path is just as robust as the blame code you just
> deleted?
I did do that research, and adding those two extra parameters was the
only thing I could find that affected prev_log_path. The only big
bugfix between November and now to log_message_receiver was in part
helped by cmpilato, and seemed to be included in prev_log_path
already.
-Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org