SVNKit: Update with UpdateClient doesn't retrieve deleted files

[Tanja.Schmidt]

Hello

 

Our application is working with svn:

1) Checkout or update from a svn repository with the SVNDepth.IMMEDIATES the directories and files. (default behaviour on startup)

2) When the user starts working on one of those directories, I update that directory with SVNDepth.INFINITE.

 

Now, some users try to revert their changes by deleting one or more directories and restart the application.

When using other clients, e.g. Tortoise or the command line client, an update will retrieve those missing directories and add them again. Svnkit 1.2.3 behaves the same.

 

But since version 1.3.0, doing an update with svnkit with

    updateClient.doUpdate(files, SVNRevision.HEAD, SVNDepth.IMMEDIATES, false, true);

 

will bring the following error:

 

Caused by: org.tmatesoft.svn.core.SVNException: svn: Directory '<...>' is missing
svn: Directory '<...>' is missing
     at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
     at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
     at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.retrieve(SVNWCAccess.java:678)
     at org.tmatesoft.svn.core.internal.wc.SVNWCManager.cropChildren(SVNWCManager.java:903)
     at org.tmatesoft.svn.core.internal.wc.SVNWCManager.cropChildren(SVNWCManager.java:940)
     at org.tmatesoft.svn.core.internal.wc.SVNWCManager.crop(SVNWCManager.java:856)
     at org.tmatesoft.svn.core.wc.SVNUpdateClient.update(SVNUpdateClient.java:526)
     at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:401)
     at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:316)
     <...>
     ... 4 more

 

Is there any option which I could use to get the same behaviour in svnkit as I have with other tools or earlier svnkit versions?

 

Thanks in advance for any help!

Best regards,

Tanja Schmidt

 

----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

[Alexander Kitaev-3]

Hello Tanja,

Sorry for delay with the answer - we were at Subversion Conference for
two days and I couldn't reply promptly.

I think what you get is expected behaviour (at least Subversion 1.6.5
behaves the same way). Most probably you have the following operations
performed:

1. checkout with depth set to IMMEDIATES - this creates wc with fixed
depth (immediates at root, empty at children folders) which is stored in
the working copy.

Equivalent command is:

svn co --depth=IMMEDIATES URL WC

2. update with depth set to INFINITY (depthIsSticky == true)

Equivalent command is:

svn up --set-depth=INFINITY WC

Note that --set-depth is used here. Working copy become 'deeper',
actually when 'infinity' is used for '--set-depth', then all information
on depth is deleted from the working copy.

3. Some directory is deleted (directory will be reported as 'missing').

4. With SVNKit: update with depth set to IMMEDIATES (depthIsSticky == true)

Equivalent command is:

svn up --set-depth=IMMEDIATES WC

SVNKit (and Subversion client) tries to 'crop' (make shallower) working
copy, which is currently has no depth limit. After this command is
executed working copy should be exactly as it was after point 1
(checkout with IMMEDIATES depth) with depth 'locked' to IMMEDIATES.

But, this operation fails, because one of the directories is missing.
This is probably a bug (exist as well in Subversion 1.6.5), but at the
same time cropping working copy is probably not something you'd like to
do. To restore missing directory you may run update with depthIsSticky
set to false.

Equivalent command is:

svn up --depth=IMMEDIATES WC

This command will restore missing directory, but not its children. Depth
will still be unlimited in the working copy, not locked to 'immediates'
and subsequent infinite update will fetch files to that directory:

svn up --depth=INFINITY WC



So, you should be aware that some variants of update (with --set-depth)
"locks" working copy to certain depth, and subsequent updates (with or
without depth specified) respect this stored depth. Changing stored
depth with another 'set-depth' update will result either in making
working copy deeper or in cropping it, which may file if some
information is missing in the working copy.

With SVNKit 'depthIsStiky' option controls whether working copy will be
'locked' to the depth specified, or whether update will merely run for
the specified depth (actully with min(specifiedDepth, wcDepth)).

Checkout depth is always considered 'sticky'. No depth stored in the
working copy considered to be 'infinity'.

Hope this information helps.

Alexander Kitaev,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!
http://sqljet.com/ - Java SQLite Library!

Tanja.Schmidt@... wrote:

> Hello
>  
> Our application is working with svn:
> 1) Checkout or update from a svn repository with the SVNDepth.IMMEDIATES
> the directories and files. (default behaviour on startup)
> 2) When the user starts working on one of those directories, I update
> that directory with SVNDepth.INFINITE.
>  
> Now, some users try to revert their changes by deleting one or
> more directories and restart the application.
> When using other clients, e.g. Tortoise or the command line client, an
> update will retrieve those missing directories and add them again.
> Svnkit 1.2.3 behaves the same.
>  
> But since version 1.3.0, doing an update with svnkit with
>     /updateClient.doUpdate(files, SVNRevision.//HEAD//,
> SVNDepth.IMMEDIATES////, *false*//, *true*//);/
>  
> will bring the following error:
>  
> /Caused by: org.tmatesoft.svn.core.SVNException: svn: Directory '<...>'
> is missing
> svn: Directory '<...>' is missing
>      at
> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
>      at
> org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
>      at
> org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.retrieve(SVNWCAccess.java:678)
>      at
> org.tmatesoft.svn.core.internal.wc.SVNWCManager.cropChildren(SVNWCManager.java:903)
>      at
> org.tmatesoft.svn.core.internal.wc.SVNWCManager.cropChildren(SVNWCManager.java:940)
>      at
> org.tmatesoft.svn.core.internal.wc.SVNWCManager.crop(SVNWCManager.java:856)
>      at
> org.tmatesoft.svn.core.wc.SVNUpdateClient.update(SVNUpdateClient.java:526)
>      at
> org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:401)
>      at
> org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:316)
>      <...>
>      ... 4 more/
>  
> Is there any option which I could use to get the same behaviour in
> svnkit as I have with other tools or earlier svnkit versions?
>  
> Thanks in advance for any help!
> Best regards,
> Tanja Schmidt
>  
>
> ----------------------------------------------------------------
> Please note: This e-mail may contain confidential information
> intended solely for the addressee. If you have received this
> e-mail in error, please do not disclose it to anyone, notify
> the sender promptly, and delete the message from your system.
> Thank you.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: svnkit-users-unsubscribe@...
For additional commands, e-mail: svnkit-users-help@...