Simon Kitching wrote:
> On Tue, 2005-06-07 at 10:08 +0100, Max Bowsher wrote:
>> Simon Kitching wrote:
>>> Hi,
>>>
>>> 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
>>> trunk.
>>>
>>> So the "trunk" dir in my working copy has a number of modified files in
>>> it.
>>>
>>> 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:
>>> http://svn.apache.org/repos/asf/jakarta/commons/proper/logging/branches/allow-flawed/
>>
>> 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
>> svnbook:
>> http://svnbook.red-bean.com/en/1.1/ch02s03.html
>>
>> 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
you like.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 10 13:53:15 2005