gnu-arch-users
[Top][All Lists]
Advanced

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

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


From: Matthieu Moy
Subject: [Gnu-arch-users] Re: Potential flaw in patch-log pruning in proposal
Date: Thu, 28 Oct 2004 09:19:33 +0200
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux)

John Meinel <address@hidden> writes:

> James Blackwell wrote:
>
> Then you can also see what other revisions contributed to it. You
> don't know exactly which did what, but you do keep context sensitive,
> and you can locate it relative to just a couple packages.

Anyway, you can still "cat-archive-log" the full file if it gets
really necessary.

> I don't think =merged is going to be all the patch logs "cat"ed
> together. It's supposed to be just the fully qualified revision name.

That's what I meant.

> I believe that's what Matthieu stated. The sum of all the patch logs
> was > 7 MB for all of the logs, but for just the list of revisions it
> is only 120Kb.

Yes, but this is for xtla which is still a very small project. If you
want Arch to replace bitkeeper for the Linux kernel for example, you
have to multiply the digits by around 100 ...

Another option is to keep the name of individual patches on a
per-version basis. That is, instead of {arch}/=merged, you'd have one
{arch}/cat/branch/ver/=merged for each version merged in the tree.
Since the location of the file gives information about the fully
qualified version name, you can just keep the patchlevels in this
file, which makes it really small.

In a project with heavy use of microbranching, this will make a lot of
small files, though.

--
Matthieu




reply via email to

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