> -----Original Message-----
> From: Les Mikesell
> On 11/29/2010 4:23 AM, Ludwig, Michael wrote:
> >>> 4. Quite (un)surprisingly, my intent is to actually find
> >>> revision, in which the destruction was made. Because, quite
> >>> (un)surprisingly, I don't know that.
> >>
> >> I'd like to be able to see the future too - but
> >> unfortunately, neither subversion nor I can do that.
> >
> > From the user's perspective, it's most definitely not the
> > future he's asking Subversion to show, but the past.
>
> Yes he is, because he is identifying the peg rev but wants the
> log to give the history of HEAD which is in the future as far as
> anything that could have been written at the time of that rev,
> and in fact is a place where the item doesn't exist.
I can see that from the peg rev point of view, HEAD is the future.
But I think we can also agree that from the SVN user's perspective,
every single existing rev including HEAD is in the past.
> > What's really needed, I think, is an index on the URL
> > maintained by the server that points to the revision ranges
> > where the node existed. That would allow me to do a lookup on
> > any given URL and quickly see whether it has ever existed, and
> > when precisely; or not at all.
>
> There's a big problem here - whether a URL exists or not usually
> isn't the right answer for things that have been deleted and
> replaced by something else of the same name. What you usually
> want is the history of only one of those things - which may
> track backwards through renames or have been copied from
> somewhere else.
Yes, there could be several items - several revision ranges - in
the index, pointing to several unrelated objects. But is it a big
problem?
In database speak, we'd indeed have a compound key for *uniquely*
identifying an object, with the first part of that compound key
being the URL, and the second part the revision. But if we don't
know the revision, we simply use the URL alone and receive a list
of all the items ever to have appeared at that URL. Which ones
we're interested in is then a matter of human decision; but gone
is the tedium (or wasteful scanning) of establishing the list in
the first place.
> A thing with the same name added later as a replacement may have
> nothing in common with the item you want. I'm not sure what the
> right test for this would be other than asking for a log with a
> rev range and a peg rev to anchor it to one specific version.
Give me a listing of the things and either require me to specify
which one I want or show them all in full detail, depending on the
circumstances. In the special case where there is only one item in
the list, no further precision is needed.
Best,
Michael
Received on 2010-11-29 18:45:55 CET