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
Received on Fri Jun 9 20:16:19 2006