Re: Reducing the pressure

Matthias Urlichs (smurf@noris.de)
30 Oct 1998 15:39:40 +0100


lm@bitmover.com (Larry McVoy) writes:
> "Matthias Urlichs" <smurf@noris.de> sayeth unto me:
> : > When your patch shows up, takepatch will detect that the patch was based on
> : > revision 1.2, not 1.5.
> :
> : Will it be able to do that if it gets a "normal" patch, without any
> : special information?
>
> Nope. It can try and /guess/ but I don't like guessing. My stuff works
> based on facts, not guesses. I realize that might be annoying, but if the
> current guessing games worked, there would be no need for me to fix them.

IMHO, there shouldn't be any confusion on which version is the common
ancestor anyway, because the archive management software knows when you
last did a merge with the common repository (whether by client-server or
by takepatch-ing a packaged update doesn't matter).

>> [common differences in diverging trees]
> RCS has this problem, but SCCS has a solution. In SCCS, you can say
> "edit revision 1.19.1.20 but also include 1.28". It is up to you (or
> some higher level tool) to figure out if that makes sense. But when you
> do that, the space cost of including that other delta is about 8 bytes.
> [...]
> I don't want xdelta because it is a binary file format.
>
Why not? I'd rather forego textual editability of the archive files if
I gain automatic smallest-diff-possible.
The management information to (semi)automatically to this isn't available,
especially not for old archives where it matters most. (Currently, checking
out some files from my local kernel archive, which happens to include a
vger mirror, takes five seconds -- simply because it has to unravel about
250 diffs and add the mostly-identical content back on). The new PRCS plus
xdelta stuff promises to cut all that out while not losing any of the
existing archive...

-- 
Matthias Urlichs  |  noris network GmbH   |   smurf@noris.de  |  ICQ: 20193661
The quote was selected randomly. Really.    |      http://www.noris.de/~smurf/
-- 
Dimensions will always be expressed in the least usable term.
Velocity, for example, will be expressed in furlongs per fortnight.

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/