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
$
Received on 2014-01-16 12:16:14 CET