C. Michael Pilato wrote:
> "C. Michael Pilato" <email@example.com> writes:
>>"C. Michael Pilato" <firstname.lastname@example.org> writes:
>>>"Steven Brown" <email@example.com> writes:
>>>>Hello, I recently moved to 0.32.1 from 0.27, and now 'svnversion .' in a
>>>>working copy that has a svn:externals directory pulled in reports the
>>>>version of the external and the version of the working copy like a mixed
>>>>copy, e.g., '106:429'. It used to ignore the external and report '429'.
>>>>This new behavior seems horribly wrong, and I assume is a bug.
>>>It's a bug. svnversion uses svn_client_status() under-the-hood, and
>>>in the newer Subversion, the status operation has learned about
>>>svn:externals. For svnversion to work correctly, svn_client_status()
>>>should take a boolean flag for including/ignoring svn:externals (which
>>>is set to "ignore" when called by svnversion).
>>Steven, would you mind testing the following patch to see if it fixes
>>this problem for you?
> Ack. Scratch that. This one's cooler. It not only ignores statuses
> after externals start getting handled -- it uses the cancellation
> callback to trigger an immediate (or at least much-more-nearly
> immediate) halting of the status operation after that point.
This depends on the status report sending everything else before the externals. Is that guaranteed by its API?
I hope that the status report will become alphabetically ordered. It might be acceptable to make an exception for externals, and still have them all grouped at the end. Note the recent talk about how the externals might well become integrated into the Entries file after version 1.0.
Perhaps the optimisation of stopping as soon as you get the first external report is over-kill, as the likelihood of someone having a very large number of externals is low.
> Start ignoring statuses (and in fact, cancel the rest of the status
> operation) at the first sign of those pesky svn:externals. They will
> taint our version range calculation.
> * subversion/svnversion/main.c
> (struct status_baton): add 'done' parameter.
> (analyze_status): Return immediately if we're done.
> (notify, cancel): New.
> (main): Initialize the baton's new 'done' parameter, and register
> the new notification and cancellation functions/batons. Also,
> check for the cancellation error return from svn_client_status(),
> which is non-fatal.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Nov 5 14:07:00 2003