Re: [Gnu-arch-users] Re: Potential flaw in patch-log pruning in proposal

[James Blackwell]

John Meinel wrote:

>
> I think the idea that the patch name gets kept, but you can optionally 
> keep the patch-log itself is a good idea. So the '{arch}/=merged' file 
> would contain the equivalent of
> tla logs --merges

There's a catch to doing this. I've meant to (and put off for) quite a
bit to build a command that lets you easily see in which revisions a
"file" was changed. 

> Or possibly with the summaries as well. (This isn't as important, and 
> might cause file size to go up again.)
>
> Then when tla wants to check if a patch has already been merged, it can 
> look for the patch-log, and secondly look for the entry in =merged.

Aye. I think this would be "good enough" for replay --skip-present. 

> It might be nicer if =merged was some sort of indexed file format, so 
> that lookups could be faster, but greping even a 120K file doesn't seem 
> very expensive.

Though I'm in favor of this, actually it can get to be quite a bit more
expensive than this. Though it wouldn't be this bad for small/medium
sized projects, larger heavily developed projects will see a
concatenated patch-log on the order of 5-6 megabytes per working
copy/revision in the library.




-- 
James Blackwell          Try something fun: For the next 24 hours, give
Smile more!              each person you meet a compliment!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400