Re: [Gnu-arch-users] Re: Fast commits

[Miles Bader]

On Sat, Apr 03, 2004 at 07:27:13PM -0500, Stefan Monnier wrote:
> I haven't figure it out yet, but I'm convinced there's a way to have our
> cake and eat it too: represent the log info more consicely without having
> to deal with nasty special diff/patch/merge ops.
> 
> I think the answer lies in redundancy: the current structure with
> {arch}/.../patch-log/patch-N files would work just as before.
> But we could also represent the same info with file with names
> {arch}/.../patch-log/patch-N-M.

Hmmm, that's clever....

In the recent discussion on this list, of `batched' patch-logs with
user-driven batching, the question of what do about overlaps (between batched
and non-batched, and overlapping batch ranges) didn't really come up; I think
the presumption was that nobody batches up patch-logs that are recent enough
to likely cause conflicts, and that the batching commands would handle
removing duplicates at batching time.  But as you say, the immutable nature
of patch-logs means that really, overlap is no problem.

In that discussion, something like .tar.gz files were used for batching
(patch-logs respond really well to lz compression); presumably the
`impossibleness' of conflicts means that using binary files is no problem in
this context (diff will always just return either file-the-same, or
new/old-file-doesn't-exist)...?

-Miles
-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen