You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Daniele <da...@interline.it> on 2006/06/09 14:51:27 UTC
problem with svn delete file, svn add file, svn log file
Hi all,
I have a problem with the following sequence:
svn add, svn delete, svn add using subversion 1.1.4-2 on debian sarge.
As you can see in the following transcript a file was added at revision
127, deleted at revision 134 and added at revision 137.
I'm not able to get the difference between revision 127 and 137
using
svn diff -r 127:137 filename.txt
but I can get the difference for the whole parent directory using
svn diff -r 127:137 .
Additionally svn log doesn't show the full story of the file but only
the logs for the newest.
Other operation like merge may be affected.
May be this issue will be solved with subversion 1.4 like the similar
I found here:
http://svn.haxx.se/dev/archive-2006-03/0918.shtml
Thanks in Advance for your suggestions,
Daniele
$ svn ls -r 126 . | grep filename.txt
$ svn ls -r 127 . | grep filename.txt
filename.txt
$ svn ls -r 133 . | grep filename.txt
filename.txt
$ svn ls -r 134 . | grep filename.txt
$ svn ls -r 136 . | grep filename.txt
$ svn ls -r 137 . | grep filename.txt
filename.txt
$ svn diff -r 127:137 filename.txt
svn: Unable to find repository location for 'filename.txt' in revision
127
$ svn diff -r 127:137 . | diffstat | grep filename.txt
filename.txt | 4 ++--
$ svn log filename.txt
------------------------------------------------------------------------
r137 | XXX | 2006-06-09 14:38:52 +0200 (ven, 09 giu 2006) | 1 line
XXX
------------------------------------------------------------------------
$ svn log -r 127 filename.txt
------------------------------------------------------------------------
r127 | XXX | 2006-06-09 08:54:05 +0200 (ven, 09 giu 2006) | 1 line
XXXX
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: problem with svn delete file, svn add file, svn log file
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 6/9/2006 11:51 AM, Daniele wrote:
> On Friday 09 June 2006 17:07, Duncan Murdoch wrote:
>
> Hi,
> the main point:
> $ svn diff -r 127:137 filename.txt
> svn: Unable to find repository location for 'filename.txt' in revision
> 127
> still make me think that something is wrong.
>
>> > Additionally svn log doesn't show the full story of the file but
>> > only the logs for the newest.
>>
>> I think that's because Subversion sees those as two different files
>> that just happen to have the same name.
>
> That sound a reasonable explanation. It's a bug or an undocumented
> feature?
I think it's actually a documented feature, but I forget where I read
it. Where I'd look is in the discussion of the @rev syntax.
> An average subversion user using snv log expect the full log history
> for the file. There should be an easy way to figure out that a previous
> version of the file one time was removed and re-added.
I think that's something that was declared by the person who added it.
If they meant "this is the same file as that old one", they would have
copied the old rev. If they meant "this is a new file that happens to
have the same name as an obsolete file", they'd do what your user did.
> Of course this is a corner case, but I think that an source control
> management system should not hide changes since one of its scope is to
> *show* (and keep track of) the changes between revisions.
But your user told Subversion that these were unrelated files.
I'd call this a user-interface issue: the user thought they were
reviving the same file, but said they were creating a new one.
Unfortunately, I don't think this is something that could easily be
fixed. When the user does the add, Subversion is documented *not* to
consult the repository. So how could it know that a file of the same
name existed long ago? It could do the test at commit time, but that's
really the wrong place for it.
Duncan Murdoch
>
>> If you really wanted to
>> revive the file, you should have copied it from rev 133, rather than
>> adding a new file with the same name.
>
> In fact I try to maintain an usable svn repository, others are screwing
> things up.
>
>> I don't think there's any way to merge the history of these two files
>> now, but if you don't have much history on the new one, you could do
>> this:
>
> I will try, next week.
> Thanks.
>
> Daniele
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: problem with svn delete file, svn add file, svn log file
Posted by Daniele <da...@interline.it>.
On Friday 09 June 2006 17:07, Duncan Murdoch wrote:
Hi,
the main point:
$ svn diff -r 127:137 filename.txt
svn: Unable to find repository location for 'filename.txt' in revision
127
still make me think that something is wrong.
> > Additionally svn log doesn't show the full story of the file but
> > only the logs for the newest.
>
> I think that's because Subversion sees those as two different files
> that just happen to have the same name.
That sound a reasonable explanation. It's a bug or an undocumented
feature?
An average subversion user using snv log expect the full log history
for the file. There should be an easy way to figure out that a previous
version of the file one time was removed and re-added.
Of course this is a corner case, but I think that an source control
management system should not hide changes since one of its scope is to
*show* (and keep track of) the changes between revisions.
> If you really wanted to
> revive the file, you should have copied it from rev 133, rather than
> adding a new file with the same name.
In fact I try to maintain an usable svn repository, others are screwing
things up.
> I don't think there's any way to merge the history of these two files
> now, but if you don't have much history on the new one, you could do
> this:
I will try, next week.
Thanks.
Daniele
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: problem with svn delete file, svn add file, svn log file
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 6/9/2006 10:51 AM, Daniele wrote:
> Hi all,
> I have a problem with the following sequence:
> svn add, svn delete, svn add using subversion 1.1.4-2 on debian sarge.
>
> As you can see in the following transcript a file was added at revision
> 127, deleted at revision 134 and added at revision 137.
>
> I'm not able to get the difference between revision 127 and 137
> using
> svn diff -r 127:137 filename.txt
> but I can get the difference for the whole parent directory using
> svn diff -r 127:137 .
>
> Additionally svn log doesn't show the full story of the file but only
> the logs for the newest.
I think that's because Subversion sees those as two different files that
just happen to have the same name. If you really wanted to revive the
file, you should have copied it from rev 133, rather than adding a new
file with the same name.
I don't think there's any way to merge the history of these two files
now, but if you don't have much history on the new one, you could do this:
Move it to a new name.
Copy the rev 133 version to the head.
Copy the changes from the new name into the head.
Delete the new name.
Commit.
I believe the syntax to do this is something like this:
svn mv repos/filename.txt repos/tempname.txt -m'temporary move'
svn cp repos/filename.txt@133 repos/filename.txt -m'revive old version'
svn update
svn cat repos/tempname.txt >filename.txt
svn commit filename.txt -m'put new revisions into it'
svn del repos/tempname.txt -m'delete temporary'
You can do the things with the temporary version entirely in your
filesystem if you like, you don't really need to involve svn in it, but
I believe the second line above requires that svn has been told to
delete the new version of filename.txt.
Duncan Murdoch
>
> Other operation like merge may be affected.
>
> May be this issue will be solved with subversion 1.4 like the similar
> I found here:
> http://svn.haxx.se/dev/archive-2006-03/0918.shtml
>
> Thanks in Advance for your suggestions,
> Daniele
>
> $ svn ls -r 126 . | grep filename.txt
> $ svn ls -r 127 . | grep filename.txt
> filename.txt
> $ svn ls -r 133 . | grep filename.txt
> filename.txt
> $ svn ls -r 134 . | grep filename.txt
> $ svn ls -r 136 . | grep filename.txt
> $ svn ls -r 137 . | grep filename.txt
> filename.txt
> $ svn diff -r 127:137 filename.txt
> svn: Unable to find repository location for 'filename.txt' in revision
> 127
> $ svn diff -r 127:137 . | diffstat | grep filename.txt
> filename.txt | 4 ++--
> $ svn log filename.txt
> ------------------------------------------------------------------------
> r137 | XXX | 2006-06-09 14:38:52 +0200 (ven, 09 giu 2006) | 1 line
>
> XXX
> ------------------------------------------------------------------------
> $ svn log -r 127 filename.txt
> ------------------------------------------------------------------------
> r127 | XXX | 2006-06-09 08:54:05 +0200 (ven, 09 giu 2006) | 1 line
>
> XXXX
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org