John Szakmeister wrote:
> ----- Branko ÄŒibej <brane@xbc.nu> wrote:
>
>> Tanaka Akira wrote:
>>
> [snip]
>
>>> I found "svn log -r COMMITTED d2/f" causes an error.
>>>
>>> nute% svn log -r COMMITTED d2/f
>>> svn: File not found: revision 1, path '/d2/f'
>>>
>>> I think it is a bug.
>>>
>>> The last committed revision should be 2 which is the commit
>>> for svn cp.
>>>
>>>
>> That's the last committed revision for d2. d2/f is the same object as
>> d1/f, and it wasn't changed in revision 2.
>>
>
> Yeah, but the new reference to the object was committed in r2, and it really should reflect that--even if it is the same underlying object. :-)
>
>
>> The real question here is: do we want to expose the fact that the FS is
>> a DAG to users like this? I have no problem with it, but it can be
>> confusing, as this conversation shows.
>>
>
> I think the answer is "no." I think it's fine that we do these things underneath the hood to conserve space, maintain history, etc. But we should always be exposing things that makes the most sense to users. In this case, one could deduce that d2/f existed before d2/... which is just weird. :-)
>
This is *exactly* what's happening, so what Subversion says is true, not
weird. :)
In the particular case of "svn log" quoted above, I'd say it's an object
resolution problem -- one that peg revs were invented to solve. The
question being asked is, "what is the svn:log property for the revision
in which the node rev I see as d2/f was committed?", and "svn log" is
obviously cutting corners when finding the answer. But I believe it's
nearly impossible to always DTRT when dealing with generic
mixed-revision working copies, regardless of how you come about them.
The other question is, how hard is this "bug" to fix? I suspect it's way
more complicated than it looks, and probably cuts all the way from the
client through the RA layers and into the entrails of the FS
implementation. Patches welcome. :)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 18 17:49:50 2006