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

Reverting File Added by Merge

From: Brian Buesker <bbuesker_at_qualcomm.com>
Date: 2005-02-28 19:03:26 CET

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

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

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
- handles 'svn' schema

$ 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

$ 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

Please let me know if you need any more information.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Received on Mon Feb 28 19:05:51 2005

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.