[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: John Szakmeister <john_at_szakmeister.net>
Date: 2006-08-19 02:39:21 CEST

----- Branko Čibej <brane@xbc.nu> wrote:
[snip]
>
> This is *exactly* what's happening, so what Subversion says is true, not
> weird. :)

Oh, I'm not debating that it makes sense from a backend perspective. It's just an odd scenario for a user because d2/f didn't exist in r1, despite the fact that it's exactly the same object at d1/f. For that matter, perhaps 'svn st' should show that d2's last change was in r1 as well... after all, we didn't change the contents of the directory we copied. :-)

>
> 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.

I believe this entirely (that it's hard to always DTRT).

> 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. :)

I'm certain you're right in that it would be hard "bug" to fix.

-John

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 19 02:39:54 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.