> --changelist behaves as a filter, one which applies after depth is taken
> into account.
>
> Now 'svn update --changelist' was an oddity in the implementation. If you
> see the bottom of notes/changelist-design.txt, you'll find this
explanation
> of how 'svn update' differs from other libsvn_client APIs which actually
> accept a set of changelists as input:
>
> 'svn update' presents an interesting challenge, too. The public
> svn_client_update3() API takes a list of paths, and returns a list
> of revision numbers to which those paths were updated. Each path is
> treated as, effectively, a separate update -- complete with output
> line that notes the updated-to revision. So, if we do changelist
> expansion outside the API, we might turn a single-target operation
> into a multi-target one, and the user sees N full updates processes
> happen. If we push 'changelists' down into the API, we can fake a
> single update with notification tricks. But that starts to get
> nasty when we look at non-file changelist support later and the
> interactions with externals and such. And if we push 'changelists'
> all the way down into the update editor, then we've got a mess of a
> whole 'nuther type, downloading tons of server data we won't use,
> and so on. [RESOLUTION: Let the command-line client do the
> changelist path expansion.]
>
This mail was buried and I almost missed it. It provides important
information. The --depth option works as a filter (in most situations) too.
And the --set-depth option is mutual exclusive with --depth. We can handle
--changelist in the same way, if needed.
Thank you very much, C. Michael
Rui, Guo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-04 21:00:50 CEST