RE: svn commit: r946661 - /subversion/trunk/subversion/libsvn_wc/adm_crawler.c

> -----Original Message-----
> From: stsp_at_apache.org [mailto:stsp_at_apache.org]
> Sent: donderdag 20 mei 2010 17:11
> To: commits_at_subversion.apache.org
> Subject: svn commit: r946661 -
> /subversion/trunk/subversion/libsvn_wc/adm_crawler.c
>
> Author: stsp
> Date: Thu May 20 15:11:07 2010
> New Revision: 946661
>
> URL: http://svn.apache.org/viewvc?rev=946661&view=rev
> Log:
> Fix issue #2267, "support uncommitted svn:externals properties".
>
> * subversion/libsvn_wc/adm_crawler.c
> (read_traversal_info): Rename to ...
> (read_externals_info): ... this. We've been using an external_func
> callback instead of a traversal info for some time.
> (report_revisions_and_depths): Rename local variable CHILDREN to
> BASE_CHILDREN for clarity (the children come from the BASE tree).
> If the caller provided an EXTERNAL_FUNC callback, check locally
> added directories for svn:externals as well and pass them to the
> callback. The caller will then pull externals into the added directory.

        Hi,

I'm not sure if this really fixes this issue for the common use cases. (And it introduces libsvn_client specific support for updates in a libsvn_wc common function that is used for more than just this update scenario. E.g. svn status -u).

The current code (well; before your patch) applies changes on svn:externals on update. By comparing the old and new versions of the svn:externals property it can add/remove/switch externals.

Your new code can just add externals, and if the directory is later reverted the externals will stay as a detached working copy. (And if a different svn:external value is set for a directory you will get some hard to resolve issues, that you would never get into with just the old code).

I think fixing issue ##2267 needs a good design instead of a quick and dirty fix in one of the fundamental editor helper functions. (E.g. does this break backwards compatibility of our APIs somewhere?)

Looking further in the implementation: Why does the code walk the children of an added noded, but not the children of the children?

        Bert
Received on 2010-05-21 11:42:57 CEST