On Wed, Apr 18, 2001 at 12:03:58AM -0500, cmpilato@collab.net wrote:
[snip]
> Let TL be an apr_array_header_t representing the target list, in
> the order it appeared on the command line. Assume that no
> "../blah" paths are allowed in the targets.
See the revised multi-args.txt I just checked in.
>
> 1. Remove redundancies from the target list: all targets that
> are descendants of some other target are removed.
>
> ...
>
[snip]
>
> Is it worthwhile to perform step 1 with attention to order (meaning,
> redundancies are defined as targets that are descendants of some other
> target *previously listed on the command line*)? If so, it means we
> are not protected from updating a single file or dir more than once in
> a single command (even though the second and subsequent updates for
> such a node should be no-ops), and this has issues for the way in
> which the update editor is driven. If not, I'll carry on with my
> change (which currently includes adding an apr_array_header_t
> TARGET_LIST argument to svn_repos_dir_delta which will be the list of
> non-redundant targets that we actually want to update (with
> SOURCE_PATH and TARGET_PATH now taking the role of the directory
> common to all the items in the TARGET_LIST).
>
> Comments? Am I on crack?
I don't know about the update editors, but I thought I would jump in and
say that condense_targets is currently written as in multi_args.txt, but
it would be an extremely simple matter to change it. I'll let wiser
heads prevail on what the semantics should be, and make sure condense
targets does as its supposed to when it is needed:)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- application/pgp-signature attachment: stored
Received on Sat Oct 21 14:36:28 2006