On Mon, 12 Aug 2002, Tom Lord wrote:
>
>
> >> * svndiff (our delta format) isn't very "cvs annotate" friendly.
> >> This is really depressing, esp. after Brane spent a lot of hard work
> >> writing a delta combiner for us. :( Thoughts about how to handle the
> >> delta-window problem wrt svndiff would be most welcome.
>
> I think arch-style revision libraries are the current best way to go
> here. Better file systems in the next few years will yield other
> approaches. If you want to be BSD specific, you could just use
> directory stacks.
>
>
>
> To expand on that a bit --
>
> Having a tool that can generate reports about various revisions and
> their relations is nice, but why should such a tool be in any way
> intricately tied to the revision control system implementation?
It's not necessarily.
>
> Why does your delta-window foo have _anything_ to do with this at all?
You do understand how cvs annotate works, and of the diff format, no?
If you did, it would be immediately clear why a delta-window that is a
combination of delta windows would be a problem for cvs annotate.
But let me spell it out for you:
cvs annotate works by simply tracking, as it combines deltas, which lines
came from which deltas (and thus, which lines came from which revisions).
Our delta combiner currently does not.
Thus, it is impossible, given a combined delta, to determine the origin of
a given line.
Now, the statement that this poses a problem is not quite correct.
The reason why is, however right.
It's just as easy/hard to do annotate as it was before, you just do it in
a different place.
The reason why annotate is difficult for us is because RCS uses a line
based format, and svndiff is byte based, it is more difficult to format.
And formatting is where the real work is. But the actual process of
getting the data necessary for annoate is not really difficult. Trying to associate it
with lines is a bit tricky.
But, anyway. Here's how stuff looks: Each revision's delta is simply
linked, in the database, to the delta of the revision before it (In
order to simplify getting all the deltas needed to generate a given
revision).
Thus, you have something that looks like (in the database. First
element of the list is the key, second is the data, third is the
link to another window or NULL.)
(foo <delta data> bar)
(bar <delta data> baz)
(baz <delta data> NULL)
Where you have a revision->delta mapping somewhere (for a given file) like
so:
(1.3 foo)
(1.2 bar)
(1.1 baz)
How to do annotate off this is quite clear, actually, with, or without a
delta combiner.
Without a delta combiner, each delta would be applied seperately, but you
would have no idea, unless you looked, that revision 1.2 started when we
hit the delta window "bar".
We don't know, or care about this, in order to get the text of revision
1.3, we just walk the windows.
So, to show there's really no problem, and that the delta combiner doesn't
make it easier or harder, ....
Before, you would have to perform the following steps:
1. For each revision starting from 1, up to the revision we need to
annotate to, grab the name of the delta window that starts that revision.
Make a nice mapping structure so that you can lookup "foo", and it'll say
"1.3"
2. As you apply deltas, and generate byte, each range of bytes generated
gets marked with the revision number associated with that window (if any. If
you don't find it in the map, it means it doesn't delineate a new
revision, and we assign it the previous number), which we lookup.
3.Now you must transform the byte ranges into *lines*, so it looks pretty.
This is done by looking at the actual content, and figuring out where each
line would break.
Each line is assigned the newest revision that touches something on that
line.
4. Boom, yer dnone.
With a delta combiner, it's the same first step, but the second step's
tracking needs to be performed *in the delta combiner* (since now *it*
is what is effectively applying the deltas to generate a combined one,
it just does so *without* actually executing the commands),
or else, you have to avoid the delta combinator, and do step two.
Doing it in the delta combiner depends on how exactly your combiner works.
>
> That's an example of a way in which svn looks too complicated to me:
> you push in here and it pops out there; delta combiner screws cvs
> annotate. Things like that shouldn't happen.
Actually, this is exactly what i would expect to happen, given the above.
With a combined delta, unless you tracked which lines came from which
delta windows as you combined them, you'd have no idea which revision
produced a given range of bytes, only that it *was* produced.
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 13 07:52:35 2002