Daniel Rall <email@example.com> 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 <firstname.lastname@example.org> wrote on 10/06/2006 03:49:32 PM:
> > I added a second status test to
> > it's included in the attached patch. It replicates what my
> > temporary test did, but actually *tests* the expected results rather
> > than relying on a manual check.
> Status.getReposLastCmtKind() seems to be redundant with getReposKind()
> (they are both accessors for the same Status.reposKind instance
> field), which has existed since 1.3. The method not used by your
> patch, so I think we can dump it.
Yes, good riddance to that.
> testOODStatus() starts off by performing an "obstructed
> checkout"-oriented check, which appears to have been copied from
> testBasicCheckout(). This isn't appropriate for testOODStatus(), so
> we can dump it.
That was trash from the start of my work on the test. Somehow it flew
under my radar.
> The method's "throws" clause follows the poor pattern
> used throughout this class TestCase by declaring "Throwable". We can
> narrow this down to "SubversionException, IOException".
Noted for any future tests I write.
> The method
> also contains some block comments with "*" formatting on every line,
> which can be switched to line comments.
> I made a bunch of other formatting tweaks and JavaDoc improvements,
Sorry about the indent formatting, I was following the style used
elsewhere in the file thinking it was something we did specific to java.
> and have committed this code in an XFAIL-style in r21908.
So that's how a JavaHL "XFAIL" is done, thanks, I had no clue. Though
we'd need to detect XPASS no?
> > > > P.S. In testing this patch I used the following hack to make the
> > > > version of svn status show all the OOD info on the command line.
> > > > also adds a temporary status test to setup various out of
> > > > It may prove useful to anyone who tries out this patch:
> > >
> > > This status test won't be permanent, then? Do we have any OOD info
> > > tests?
> > No, because it relies on the hack I made to the debug version of svn
> > status, so it isn't really usefil. The JavaHL test will replace it
> > above).
> Some of the Python status tests do check for "*", but don't test the
> individual pieces of "out of date" information retrieved from
You're making this statement for the benefit of others reading this yes?
Or is there a question for me in here? :-)
Updated log and patch to r21914 included.
Our remaining issues(?):
A) The performance of svn_repos_deleted_rev()
B) Possible side effects of passing wrong revision to svn_delta_editor_t
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).
(testOODStatus): Remove XFAIL-style catch.
(svn_repos_deleted_rev): New function to find the revision a path was
most recently deleted within a give revision range.
(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.
(svn_repos_deleted_rev): New function definition.
(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
(delete_entry, close_file): Supply new args to tweak_statushash()
(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.
Received on Fri Oct 13 16:51:49 2006
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org