[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Was: Enhancement needed in svn status -u

From: Paul Burba <paulb_at_softlanding.com>
Date: 2006-10-25 21:55:49 CEST

Daniel Rall <dlr@collab.net> wrote on 10/25/2006 02:55:09 PM:

> I've created a temporary branch, "ood-status-info", so we have a place
> to work on refining these fixes.
>
> On Fri, 13 Oct 2006, Paul Burba wrote:
>
> > Daniel Rall <dlr@collab.net> wrote on 10/12/2006 05:37:45 PM:
> >
> > > [Focusing on the Java/test portion of this thread.]
> > >
> > > On Wed, 11 Oct 2006, Paul Burba wrote:
> > >
> > > > Daniel Rall <dlr@collab.net> wrote on 10/06/2006 03:49:32 PM:
> ...
> > > and have committed this code in an XFAIL-style in r21908.
> ...
> > Though we'd need to detect XPASS no?
>
> Yeah, we want to report an unexpected pass. I've done so on trunk in
> r22112.
>
> ...
> > > Some of the Python status tests do check for "*", but don't test the
> > > individual pieces of "out of date" information retrieved from
> > > repository.
> >
> > You're making this statement for the benefit of others reading this
yes?
> > Or is there a question for me in here? :-)
>
> Yup.

'Yup' to which question? "Would you like coffee or tea?", "YES!" :-)
 
> ...
> > Our remaining issues(?):
> >
> > A) The performance of svn_repos_deleted_rev()
>
> This is currently too slow to integrate into trunk. Let's write a
> faster implementation -- hopefully we can speed things up by moving
> the logic down inside the FS layer.

I'll post a separate message to catch the attention of FS gurus and get
their opinion.

> > B) Possible side effects of passing wrong revision to
> > svn_delta_editor_t delete_entry() implementations.
>
> Any findings here?

Short answer is no. I gave the long answer earlier in this thread:

  http://svn.haxx.se/dev/archive-2006-10/0344.shtml

If my answer there isn't satisfactory let me know.

Paul B.

> I've committed the following patch to the "ood-status-info" branch in
> r22116:
>
> > [[[
> > Further improvements to status information on working copy items which
> > are out of date compared to the repository.
> >
> > Follow-up to r16344 (and its subsequent follow-ups: r16494, 16784,
16796,
> > 16829, 17844, and 21908).
> >
> > * subversion/bindings/java/javahl/src/org/tigris/
> > subversion/javahl/tests/BasicTests.java
> > (testOODStatus): Remove XFAIL-style catch.
> >
> > * subversion/include/svn_repos.h
> > (svn_repos_deleted_rev): New function to find the revision a path
was
> > most recently deleted within a give revision range.
> >
> > * subversion/libsvn_repos/reporter.c
> > (update_entry, delta_dirs): Use the new function
svn_repos_deleted_rev()
> > to determine the revision deleted paths were deleted and pass this
to
> > the delete_entry callback rather than defaulting to
SVN_INVALID_REVNUM.
> >
> > * subversion/libsvn_repos/rev_hunt.c
> > (svn_repos_deleted_rev): New function definition.
> >
> > * subversion/libsvn_wc/status.c
> > (tweak_statushash): Add second baton argument which contains the out
> > of date info for a dir baton when tweaking that baton's parent. Add
> > another argument to identify the revision a path was deleted when
> > handling deletes. When deleting paths: Construct the correct url
for
> > the path and record deleted path's deleted revision in the path's
> > svn_wc_status2_t structure. For pre-1.5 servers, which don't
provide
> > the deleted revision, use the parent's last committed rev as a best
> > guess.
> > (delete_entry, close_file): Supply new args to tweak_statushash()
> > calls.
> > (close_directory): Tweak status for directories even when the only
> > change is that they have and an out of date descendents. Supply new
> > args to tweak_statushash() call.
> > ]]]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 25 21:56:25 2006

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.