Re: svn cp + svn log reports files as status R
Simon Kitching wrote:
> On Tue, 2005-06-07 at 10:08 +0100, Max Bowsher wrote:
>> Simon Kitching wrote:
>>> I've been working on some code in trunk; it has got a little more
>>> complex than I originally thought so I decided to check it in as a
>>> branch "allow-flawed" so people can review it without me damaging the
>>> So the "trunk" dir in my working copy has a number of modified files in
>>> I did:
>>> cd branches
>>> svn cp ../trunk allow-flawed
>>> svn commit allow-flawed
>>> [r188671 created]
>>> svn log -v -r188671:HEAD allow-flawed
>>> The output of the svn log command shows about a dozen files/directories
>>> as status "R" (replaced???). These files certainly have *not* been
>>> deleted/readded in trunk. And many of them are files that haven't been
>>> touched for ages.
>>> Any ideas what I might be doing wrong here?
>>> The repo in question is publicly accessable:
>> Those replace operations are recording the mixed-revision status of your
>> working copy at the time of the "svn copy".
>> For more info on mixed revision working copies, see this section of the
>> The short version is: Use "svn update" to bring your working copy to a
>> single revision unless you deliberately *want* to make use of
>> mixed-revision copies.
> Thanks Max. I have experimented with this following your info and pinned
> down the circumstances that triggered this in my case.
> When a directory is copied via "svn cp" from a working copy and the
> directory revision# cached in .svn/entries is older than a file in that
> directory then the file is marked as "R" in the new commit.
> In other words, this process will duplicate the problem:
> * in dir "foo", svn update (eg to r100)
> * edit a file bar.txt and commit. file becomes r101
> * svn cp foo foo2
> * svn commit foo2 (generates r102)
> --> bar.txt is reported as "R" because foo2 is a copy of r100 but
> contains r101 of bar.txt
> I do understand why subversion does this, but it is definitely
> inconvenient and non-intuitive from the user point of view.
> And running "svn update" isn't always desirable in this situation. The
> point is that the working directory is just the way I want to copy it.
> Any suggestions?
You don't have to update to HEAD. You can update to any specific revision
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Jun 10 13:53:15 2005
This is an archived mail posted to the Subversion Users