[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: svn_client_update2 doesn't update directories. svn up does ?? ???

From: Byron Whitlock <bwhitlock_at_STORMFRONT.com>
Date: 2006-03-16 23:59:43 CET

The main problem here is somehow the repository got to a state where
the client thinks it is up to date, but is missing a directory in the
entries file and in the working copy.
I am still tracking down how this happened in the first place....

This is the same state as when you do a svn co -N (except svn puts all
subdirectories in this state).

The second problem is the difference between the way the svn works, and the
"UI" is a folder neither in the working copy nor the entries file.

C:\projects\Testdb\Prospero\Local Assets>svn up
At revision 272.

C:\projects\Testdb\Prospero\Local Assets>svn up "UI"
A UI\XBox\Textures
Updated to revision 272.

If I make the equivalent call to svn up "UI" using svn_client_update2, I
just get 'svn_wc_notify_skip' in the notification callback. Nothing gets

Here is a snippet of code...
svn_opt_revision_t revision;


apr_array_header_t* pPathsToUpdate = apr_array_make(mpMemoryPool, 1,
sizeof(const char*));

APR_ARRAY_PUSH(pPathsToUpdate, const char*) = absolutePathToUpdate.c_str();
// this is 'C:\projects\Testdb\Prospero\Local Assets\UI' in the prev example

apr_array_header_t* pRetrievedRevisionNumbers;

                        true, //recurse
                        false, // ignore_externals

my notification callback
void ClSubversion::defaultNotifyFunc(void *baton, const svn_wc_notify_t
*notify, apr_pool_t *pool)
        ClSubversion* const pSvn = reinterpret_cast<ClSubversion*>(baton);

        NotifyInfo info;
        info.lockState = (notify->lock_state ==
svn_wc_notify_lock_state_locked) ? true :false;
        info.makeReadOnly = false;
        info.action = (ClSubversion::NotifyAction)notify->action;

        switch (notify->action)
                case svn_wc_notify_skip:
                info.operation = " Skipping a path. " ;

-----Original Message-----
From: rooneg@gmail.com [mailto:rooneg@gmail.com]On Behalf Of Garrett
Sent: Wednesday, March 15, 2006 9:16 PM
To: Byron Whitlock
Cc: dev@subversion.tigris.org
Subject: Re: svn_client_update2 doesn't update directories. svn up does

On 3/15/06, Byron Whitlock <bwhitlock@stormfront.com> wrote:
> I have an MFC client written to the 1.2.3 API. We are using a vanilla
> server.
> We have a huge 30GB+ repository shared by about 50 users.
> It appears the svn_client_update2 function isn't always updating
> that exist in the repository.
> I add a directory "foo" to the root of the repository and commit it.
> On another machine when I do "svn up foo", I can see the new "foo"
> being added.
> However when I make the svn_client_update call, all I get is "Skipped a
> path" from the notification callback.
> If I try to update the parent directory with svn_client_update2, I don't
> get any notification at all (Svn up works okay). It's like Subversion
> doesn't even know about the newly added directory.
> I can reproduce this on my machine by
> 1) removing the "foo" from the entries file and
> 2) deleteing the "foo" directory from the locally copy.
> svn up consistently brings the directory back, but svn_client_update2 does
> not.
> When I trace thru the subversion code, I see svn_client__update_internal
> I've experimented with everything I can think of and I am at a loss.
> Can someone shed some light on this problem?

You're going to have to be rather more specific, showing us some
example code that reproduces the problem would be a good start.

> This seems like it may be related to the "svn co -N " bug (#695 i think)

Fron your current description I can't see how you would reach that
conclusion. Are you actually using nonrecursive checkouts?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 17 00:00:05 2006

This is an archived mail posted to the Subversion Dev mailing list.