On Thu, Jan 16, 2014 at 02:08:47AM -0800, Yuri wrote: > I first described my issue in the form of the Issue ticket: > http://subversion.tigris.org/issues/show_bug.cgi?id=4462 but it was promptly > closed for unclear reasons. > The explanation in this ticket says "you somehow deleted your current > directory". Well, I am positive I did not. > > In short: I had the checked out subversion directory. Somebody else added > few files into the repository, then I deleted the enclosing sub-directory, > updated it with 'svn update', and the added by others files failed to > appear. And they also failed to appear after overall 'svn update'.
This sounds as if you should have gotten a tree conflict marked in your working copy. Is this the case? If so, we can help you resolve it if you provide some additional details. If no tree conflict was flagged, then I'm not sure what state you're working copy is in and would need more information. Which Subversion client are you using, and which version? Do you have a command line client available? If so, can you check the output of 'svn status' when run on the problematic working copy? Does it mention tree conflicts? If you're unsure how to interpret the output please paste it into an email so others can see it. I'll explain what I see with Subversion 1.8 when I try to reproduce your problem based on the description you've given. A transcript of commands typed, and their output, is given below. I have a directory 'epsilon' in my working copy at r3. And I've locally deleted 'epsilon' in my working copy. In r4 a new file 'new.txt' was added to 'epsilon' in the repository. I update to r4 and get a tree conflict flagged, for which the client open a conflict resolution menu. There are two relevant options: (mc) prepare for updating moved-away children, if any (recommended) (p) postpone Because I didn't move any children out of epsilon before deleting it, I can just choose 'postpone'. To resolve the conflict, I revert the deletion of 'epsilon' which brings the newly added files back into my working copy (note that 'svn revert' removes conflict markers since reverting the working copy to its BASE revision implies the acceptance of the incoming conflicting change). If I then wanted to remove 'epsilon' again I could so by running 'svn rm epsilon'. The other option is to do nothing and keep the 'epsilon' directory as it is. Does this example help? If you're seeing a different problem, can you try to phrase your problem in a similar manner and provide a transcript? Thanks! $ svn status D epsilon D epsilon/zeta $ svn up Updating '.': C epsilon A epsilon/new.txt Updated to revision 3. Summary of conflicts: Tree conflicts: 1 Tree conflict on 'epsilon' > local dir delete, incoming dir edit upon update Select: (mc) prepare for updating moved-away children, if any (recommended), (p) postpone, (q) quit resolution, (h) help: p Summary of conflicts: Tree conflicts: 1 $ svn st D C epsilon > local dir delete, incoming dir edit upon update D epsilon/new.txt D epsilon/zeta Summary of conflicts: Tree conflicts: 1 $ svn revert -R epsilon Reverted 'epsilon' Reverted 'epsilon/zeta' Reverted 'epsilon/new.txt' $ ls epsilon/ new.txt zeta $ svn status $ svn rm epsilon D epsilon D epsilon/new.txt D epsilon/zeta $ svn status D epsilon D epsilon/new.txt D epsilon/zeta $