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

Re: svn cp + svn log reports files as status R

From: Simon Kitching <skitching_at_apache.org>
Date: 2005-06-09 13:01:37 CEST

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?

Regards,

Simon

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 9 13:02:43 2005

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