[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Miles Bader
Subject: Re: [Gnu-arch-users] Re: Fast commits
Date: Sat, 3 Apr 2004 19:55:03 -0500
User-agent: Mutt/1.3.28i

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]