You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Simon Kitching <sk...@apache.org> on 2005/06/07 04:03:30 UTC
svn cp + svn log reports files as status R
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/
Thanks,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn cp + svn log reports files as status R
Posted by Simon Kitching <sk...@apache.org>.
On Tue, 2005-06-07 at 16:03 +1200, 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/
NB: might it have something to do with this bug being worked by Karl
Fogel?
http://subversion.tigris.org/issues/show_bug.cgi?id=1553
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn cp + svn log reports files as status R
Posted by Max Bowsher <ma...@ukf.net>.
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
Re: svn cp + svn log reports files as status R
Posted by Simon Kitching <sk...@apache.org>.
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
Re: svn cp + svn log reports files as status R
Posted by Max Bowsher <ma...@ukf.net>.
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.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org