To: John Meinel <tla@johnmeinel.com>
References: <20041025210724.GA19744@merconline.com>
	<200410272144.i9RLiYnd074868@xl2.seyza.com>
	<vpqoeinq0aw.fsf@ecrins.imag.fr> <418023CD.1000504@johnmeinel.com>
	<20041028023254.876A91436C5@comet.merconline.com>
	<418070AF.1070503@johnmeinel.com> <vpqoeincnsq.fsf@ecrins.imag.fr>
From: Miles Bader <miles@lsi.nec.co.jp>
System-Type: i686-pc-linux-gnu
Blat: Foop
Date: Thu, 28 Oct 2004 17:39:07 +0900
In-Reply-To: <vpqoeincnsq.fsf@ecrins.imag.fr> (Matthieu Moy's message of
	"Thu, 28 Oct 2004 09:19:33 +0200")
Message-ID: <buor7njz178.fsf@mctpc71.ucom.lsi.nec.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: gnu-arch-users@gnu.org, James Blackwell <jblack@merconline.com>
Subject: [Gnu-arch-users] Re: Potential flaw in patch-log pruning in	proposal
Precedence: list
Reply-To: Miles Bader <miles@gnu.org>
Sender: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Errors-To: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Status: RO
Content-Length: 967
Lines: 17
If you're worried that even the list of _revision names_ can get too
long, you can use a range format like:

   foo@bar/x--y--0--patch-25-107

That was my idea for making aggregated/compressed log files fast too --
encode the set of patches represented into the name of the aggrate.
E.g., you'd have files like `patch-10-100.tar.gz' which would contain
patch-10 through patch-100.  Then the check for patch existance would be
actually even faster than it is now, no uncompression needed.  [The
`cat-log' command would have to uncompress the whole thing to get a log
file, but that's probably alright.]

-Miles
-- 
Come now, if we were really planning to harm you, would we be waiting here, 
 beside the path, in the very darkest part of the forest?


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/