> 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).
Thats not correct.
You get the diff to the current revision(s) of the working copy.
In general, this is different from the diff to the previous revision.
>
> 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*.
Subversion uses the so-called "snapshot model" of version control.
In Subversion, the originally purpose of a revision is unique identifying
a snapshot.
However, some Subversion commands (mis)use a revision also for
identifying the change leading to this snapshot.
I think Michael's analysis describes this very well.
>
>> 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.
In most changeset based version control systems, it is very hard
to get the history of a single object at all.
Cheers
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 11 11:21:20 2007