Brummer, Byron wrote:
> Rob van Oostrum [mailto:rob.vanoostrum@blastradius.com] wrote:
>> Your example is flawed.
>
> My example is not flawed. That it fails is a flaw,
> in the tool. That's the point.
Maybe here is where there is a bit of confusion still. Like I posted
before, I was confused by this before and see the UI confusion of this.
However, the question is actually much easier to understand if you
look at what a revision is.
At r33 there is no file there any more. It was deleted in the transition
from r32 to r33. Note that r33 does not describe the transition, it
describes the state of the repository *after* the transition from r32 to r33.
This is, unfortunately more confusing due to the svn log command and the
was most of us talk about things. The svn log command really shows what
the actions were that produced the revision in the log, not the actual
revision. After all, the actual revision contains all of the files/directories
in the repository, not just what was changed.
It is invalid to talk about a path at r33 if it was deleted in the
transition between r32 and r33. It does not exist in r33, period.
Now, the UI question is, how do we describe the transition (r32->r33) vs
the revision (r33) for certain commands. It may be that this is the
fundamental confusion that we are running into here.
[...]
>> 'svn log -r33 file:///home/bbrummer/test/test_repo/test.txt_at_32'
>> does not work because you're correctly pegging at r32, and then
>> try to look forward to r33, where the file no longer exists.
>
> Thank you again for clarifying exactly why SVN is broken.
> Two points:
>
> A) r32 is a valid peg version for the object I'm
> interested in.
>
> B) r33 is a valid historical log relating to the object
> I'm interested in (test.txt@32).
I think this just shows the confusion even more. r33 is not a historical
log for the test.txt file. It does not exist there. The transition from
r32 to r33 has some information about the file (and in this case the
deletion) but at r33 (and r34, r35, etc) the file does not exist.
The real question/problem is the inconsistency of the reporting of the
transition vs the next repository state. A revision is a complete repository
state.
> I know how SVN is broken so you restating it doesn't offer
> any progress on the subject.
You are unfair it claiming that SVN is broken. There are UI confusions due
to the difference between a revision and the transition between rN and rN+1
(or any two revisions)
This is what, to me, seems to be the core confusion. And is made worse by the
way svn log reports those transitions.
This reminds me of the "big" mind shift some people had when a text cursor
changed from "block" to "insert point" - the cursor, even as a visual block,
was never really on the character it visually was on but rather in the space
between that character and the one before it. Display devices just did not
have a way to handle that until the bitmapped displays that are common now.
Now, no one even questions this behavior and text selection is very obvious,
but this caused all sorts of problems before this "shift" was completed. To
me, the svn log output is much in the same way. There really is no log
entry for a revision, just for the step from one revision to another.
> How can anyone seriously argue that the removal of an
> object is of no historical significance to the object?!
I don't think anyone is - we are arguing that your addressing of the object
using the revision where it no longer exists is fundamentally invalid. That
address is not valid and thus can not be used to find/show that object. Much
like having the cursor after the last character on the line - say character 71.
What does it mean to ask about the character at 72? There is no such character.
But where is the cursor? Is it on 71? No. Is it on 72? There is no 72, so
it can not be on that character. See the addressing confusion? Same here.
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 11 06:02:10 2007