Karl Fogel wrote:
> "Rui, Guo" <timmyguo_at_mail.ustc.edu.cn> writes:
>> The second is the --changelist, which seems to honor the depth option in the
>> implementation of "svn update". I'd not had time to read the document about
>> it yet. So, does it interfere with the logic of sparse-directories?
>
> Er, actually I don't know. Do you see any interfering behaviors?
--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.]
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
---------------------------------------------------------------------
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 07:53:10 CEST