(I'll leave arch-dev in the cc line since it's Tom's list and he seems
to want it there; apologies for those who don't have enough context to
understand this.)
On Tue, 2002-08-13 at 01:08, Tom Lord wrote:
> > Some of your issues fit in the category of "subjective and somewhat
> > arbitrary,"
> Please catch up with my messages from earlier this evening and then
> re-raise this issue if you still believe it.
Yup. Here are the arguments I saw you raise, if I understand them:
1. Subversion working copies should be the same as distributable source
trees.
2. We should be providing tools so that people can make lots of changes
in separate directories without doing their own bookkeeping.
3. Our fundamentals should make it easy to have distributed operation.
4. Our lines-of-code count is too high.
5. We smoosh together Apache and webdav integration.
6. Our working copy model is too hard to implement.
7. Targeting operational compatibility with CVS such a bad idea as to be
termed "a cliche" when we use it as an argument.
8. It makes no sense for our delta format to be targeted towards making
"svn blame" easy.
I'd say all of these claims are subjective and somewhat arbitrary. One
could have long, drawn-out arguments about any of them, and potentially
reach either conclusion. We made explicit or implicit decisions about
all of them, except #8, a long time ago. We made an explicit decision
about #7, from which our decisions on #1 and #6 follow directly, and
from which our decisions on #2 and #4 follow indirectly.
You may be confused about #5, but I'm not sure; I couldn't tell quite
what you meant there. We don't implement DAV ourselves. It's possibly
that we could separate libsvn_ra_dav from the dav-to-libsvn_fs
translation semantics, but I think that would amount to gratuitously
inventing a DAV back-end API and then translating Apache's API to ours.
#3 is too vague to really evaluate.
On #8, I think some explanation will suffice: the "cvs annotate"
operation labels each line of source with the last revision it was
modified in. (Revision libraries don't do anything of the sort,
incidentally; finding out when line 637 of a source file was last
modified and who did it is not a trivial operation given a complete
revision library.) The RCS file format makes this easy because it uses
a series of line-based diffs; you can simply make a pass over the file
marking up an array and quickly produce the needed annotations. We, on
the other hand, use compressed binary deltas, which don't give much
insight as to which data was modified between two revisions. Bill Tutt
is interested in trying to coax a solution out of binary deltas (which I
think is futile); other possible solutions include making "svn blame" a
slow operation (having it construct line-based diffs between each
revision of the file), storing annotation information in the repository
with each revision, or using line-based diffs instead of binary deltas
in the repository for text files. None of the options are terribly
appetizing; "svn blame" isn't a common operation, so it shouldn't
dominate the storage scheme, but it shouldn't be intolerably slow
either.
The delta combiner has nothing to do with the problem, really. That's
just where a lot of the work would be done *if* Bill Tutt has the right
idea, which I think he doesn't.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 13 08:08:29 2002