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
> 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
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.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Jun 9 13:02:43 2005