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

RE: Delete revision of an object has no peg revision?

From: Brummer, Byron <ByronBrummer_at_LiveNation.com>
Date: 2007-01-11 10:57:10 CET

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
> 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
> from r32 to r33. Note that r33 does not describe the transition, it
> describes the state of the repository *after* the transition from r32
> 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)
> 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
> 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.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 11 10:58:28 2007

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

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