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

Re: svn status -v

From: Branko Čibej <brane_at_xbc.nu>
Date: 2006-08-18 17:45:19 CEST

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

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.