On 04/14/10 20:18, Max Battcher wrote:
All of which goes to show that Trac+darcs still isn't well optimized for caching darcs queries or dealing gracefully with with long running command invocations... I still say the Trac reliance on CVS/SVN-style revision numbers means that Trac is absolutely not well-adapted for serving darcs repositories. It may be "revision 1782" to Trac, but 'show contents --match "hash 2008..."' is "commute this file to how it would appear if only the patches preceding or equal to this one with a timestamp from two years ago were applied" to darcs. (Which ends up being quite possibly not a "real" historic version at all,
Well, suppose you have a public darcs repository for a project. (Such as GHC HEAD.) If you look at the history of the real world (as opposed to darcs' conception of history), this repo contained a series of states over time. What infrastructure would we need, to be able to look at this series usefully/efficiently years later? (I am reckoning that this concept of history is useful enough that it's worth creating whether or not darcs itself can support it. Does anyone agree/disagree?)
-Isaac _______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
