On Fri, Apr 23, 2010 at 06:23:49AM -0400, Greg Stein wrote:
> On Fri, Apr 23, 2010 at 05:38, Daniel Näslund <daniel_at_longitudo.com> wrote:
> > I wanted to keep the current behaviour since the status code is involved
> > in so _many_ tests and rewriting all of those would cause me to loose
> > momentum. Guess, what? I've already lost that momentum. :)
>
> I suspect you mean svn/status-cmd.c rather than "status code". The
> real point is "how does 'svn status' present the values in
> svn_wc_status3_t?". You can provide wc-ng semantics in that structure,
> and then let status-cmd map those into old-style semantics and
> display.
>
> Then, in a future step, we can discuss altering the output of
> status-cmd to make more sense and to eliminate all the ugliness.
Ok, how about creating something like this. To be called from inside the
status callback for compatibility with the testsuite (a temporary thing
of course).
/* Get the working revision of @a local_abspath using @a wc_ctx. If @a
* local_abspath is not in the working copy, return @c
* SVN_ERR_WC_PATH_NOT_FOUND.
*
* This function is meant as a temporary solution for using the
* old-style semantics of entries. It will handle any uncommitted
* changes (delete, replace and/or copy-here/move-here).
*
* For a delete the @a revision is the BASE node of the operation root,
* e.g the path that was deleted. But if the delete is below an add,
* the revision is set to SVN_INVALID_REVNUM. For an add, copy or move
* we return SVN_INVALID_REVNUM. In case of a replacement, we return the
* BASE revision.
*
* The @changed_rev is set to the latest committed change to @a
* local_abspath before or equal to @a revision, unless the node is
* copied-here or moved-here. The it is the revision of the latest
* committed change before or equal to the copyfrom_rev. NOTE, that we
* use SVN_INVALID_REVNUM for a scheduled copy.
*
* The @a changed_date and @a changed_author are the ones associated
* with @a changed_rev.
*/
svn_wc__node_get_working_rev_info(svn_revnum_t *revision,
svn_revnum_t *changed_rev,
apr_time_t *changed_date,
const char *changed_author,
svn_wc_context_t *wc_ctx,
const char *local_abspath,
apr_pool_t *scratch_pool,
apr_pool_t *result_pool);
It will consist of the code I've put inside assemble_status() in the
previous patch. While we want this behaviour for the status callback:
print_status(..., svn_wc_status3_t *status)
{
if (status->replaced)
Get the info from BASE
if (status->add/copy-here/move-here)
Use the info inside svn_wc_status3_t (as described for read_info())
if (status->deleted)
if (status->inside_an_add)
/* I have no idea really */
else
not_yet_implemented_get_base_of_delete()
}
Ok, 'we want' is really 'I think we want' but you get the idea.
There is no way to detect those states from the callback.
status->text_status was _not_t the way to go. I didn't get any specific
reasons to why, but I'm assuming it maps poorly to the new states in
svn_wc__db_state_t. And the temporary svn_wc__node_is_status_{added,...}
had a couple of quirks with not detecting obstructed_add and so on.
Using the function I outlined above I can let status->revision be easily
defined while still beeing compatible with the testsuite.
Maybe we should create svn_wc_status_kind2_t to make the relevant db
states available to the upper layers.
[...]
Cheers,
Daniel
Received on 2010-04-23 17:02:03 CEST