Jeremy, I'm surprised by your reported behavior. The Subversion
command-line client manages to get all the permutations of its status
output using a single call to svn_client_status2(), so I have to believe
that the function behaves as expected. Are you able to share the
relevant bit of code with us?
Jeremy Statz wrote:
> I'm tinkering with a client that does per-folder updates using
> svn_client_status2, and I'm confused by its behavior. When I call
> svn_client_status2, I am returned a status baton that contains a list of
> the files in the specified folder and their local status, plus the
> status of the folder itself.
> The eighth argument is "update",which is theoretically supposed to
> request the current status of the specified folder's contents. However,
> when I call the function the same way but with update=true, I no longer
> get a list of files. I only get the folder itself and its status --
> none of its contents are in the list. This means that when the client
> tries to refresh the status of files in the folder, I can't find out if
> a file is actually out of date relative to the repository. We've got a
> number of nontechnical users, so I consider it pretty important to have
> an "out of date" marker.
> Tinkering with this, I've found that if I set update=true, AND
> recurse=true, then I get a proper list with repository status and all...
> but then I'm stuck with all of the files in all of the subfolders too.
> Our local repository is substantial, so simply trimming out the rest of
> the list is out of the question (doing the request with recursion takes
> a long time).
> I did some Google searches and found a couple questions about this but
> no answers, and the inconsistancy in behavior between update being true
> or false seems really strange. Am I missing something here, or is this
> a bug? Is there a workaround other than recursing all the time?
> To unsubscribe, e-mail: email@example.com
> For additional commands, e-mail: firstname.lastname@example.org
C. Michael Pilato <email@example.com>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Tue Oct 24 18:23:54 2006