Repost: Reverting File Added by Merge

[Brian Buesker <bb...@qualcomm.com>]

Reposting this question as I never received a response. Sorry if people 
just haven't gotten a chance to answer it yet.

I ran into the following problem with trying to revert a file that was 
added by an svn merge. When the file that I want to revert is contained 
within a directory that was also added by the merge, and I do an svn 
revert on the file and then commit, the file that I reverted still 
exists in the repository although it is no longer listed in 
.svn/entries. For example, if I do an svn merge which results in the 
following:

A  dir1
A  dir1/file1

and then I do an svn revert on dir1/file1, the file is no longer 
versioned in my working copy as shown by svn status:

?      dir1/file1
A  +   dir1

However, if I then commit and check the repository, file1 exists in the 
repository even though it does not exist .svn/entries. Once I reach this 
point, the only way I'm able to remove it from the repository is either 
through an svn rm with the URL or an svn update dir1/file1 (after 
removing the unversioned file first) and then an svn rm dir1/file1. An 
svn update with no arguments does not restore dir1/file1 (I assume since 
it is not in .svn/entries).

The two workarounds I have found so far are:

  1. First commit the added directory and then remove the file using
     svn rm.
  2. Recursively revert the added directory, and then re-add it (only
     adding the files you want).

My guess is that the problem I am seeing stems from the fact that the 
added directory has a copyfrom-url, so in the repository it is just a 
copy of the directory from the DST component of the merge, and that the 
working copy is not storing state after the revert to indicate 
otherwise. This is just an educated guess though, as I have not looked 
at the code. I tested this situation with the svn /trunk and it appears 
to exist there as well.

In the above situation, is a developer expected to use one of the two 
workarounds I mentioned, or is this a bug?

I have attached a script which can be used to reproduce what I am 
observing.

Here is my environment:
OS: Fedora Core 3

SVN Version (also exists in /trunk):
$ svn --version
svn, version 1.1.2 (r12471)
compiled Jan  7 2005, 15:34:50

Copyright (C) 2000-2004 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet 
(http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
- handles 'http' schema
- handles 'https' schema
* ra_local : Module for accessing a repository on local disk.
- handles 'file' schema
* ra_svn : Module for accessing a repository using the svn network 
protocol.
- handles 'svn' schema

Compiler:
$ gcc --version
gcc (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Perl:
$ perl -v

This is perl, v5.8.5 built for i386-linux-thread-multi

Copyright 1987-2004, Larry Wall

Perl may be copied only under the terms of either the Artistic License 
or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'.  If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.

Berkeley DB Version: 4.2.52

OpenSSL Version:
$ rpm -q openssl
openssl-0.9.7a-40

Please let me know if you need any more information.

Thanks,
Brian