Michael Sinz [mailto:Michael.Sinz@sinz.org] wrote:
> 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.
IMO it does describe the transition (otherwise we'd have E for
Exists instead of A for Add, etc. A given revision describes
how to get from rev A to rev B inclusive. Hell, when you ask
svn to update your working copy to a new revision what you are
*actually* doing is not pulling the complete state of the target
revision but rather you are pulling the *transition* instructions
required to get you there (the diff that gets applied).
If r33 described the state of repo at r33 the log entry would
show you every file that *does* exist. But it doesn't do that,
no, rather it shows you what files *must be removed* in order
to get there. IOW it shows you the *transition*.
> 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.
It is invalid to consider the removal of an object to be of no
historical relevance to that object.
> 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.
However you want to describe it, it's part of the object's history.
A query for that history should display it. *Not* displaying
one of the most important historical events that can happen to
an object is invalid.
> 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.
Show me a sane way to retrieve the full history of an object
and I'll shut up. Until then I'm being more then kind by
only claiming svn is broken. Seriously, we are talking
about a historical database that is flatly *incapable* of
providing the complete history of an element without
requiring the user to jump through a maze of complex hoops.
> > 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.
Again, show me a sane way to retrieve an object's complete
history and I'll drop the subject.
-Byron
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 11 10:58:39 2007