[Top][All Lists]

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

Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)

From: Nathaniel Smith
Subject: Re: [Monotone-devel] Re: big repositories inconveniences (partial pull?)
Date: Tue, 29 Aug 2006 04:37:45 -0700
User-agent: Mutt/1.5.12-2006-07-14

On Tue, Aug 29, 2006 at 09:28:51AM +0200, Markus Schiltknecht wrote:
> If we store the original RCS version as a file attribute, how can the 
> end-user query what CVS files he got with a given MTN revision? Where 
> could we save 'per revision' information? (The 'all CVS commits were 
> between 27/08/2006 15:42:13 and 27/08/2006 15:42:19' or even: 'this 
> revision overlaps in CVS with MTN revision 359a3f2...' things)?

Perhaps an attr on the root dir?

> And can we somehow ensure, that the file attribute gets deleted after 
> the first MTN commit? It seems irritating to have the latest RCS version 
> attached to all files after that.

It might be nice, but if there are no use cases besides CVS, it's very
hard to justify extending the core model to add such "temporary

> (My understanding is that such information would much better fit into a 
> per revision cert, instead of file attributes, which sounds somewhat 
> like a hack. But I guess compressing or even delta-compressing certs is 
> not an option, huh?)

Not really... there's never anything natural to delta-compress
against, since each cert stands alone (unlike files and rosters,
which are inherently tied up in a history), and most certs need to be
accessible very quickly (e.g., we have an sqlite index for "give me
all branch=net.venge.monotone" type queries...).

-- Nathaniel

Eternity is very long, especially towards the end.
  -- Woody Allen

reply via email to

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