Alec Thomas wrote:
On Wed, May 03, 2006 at 12:25:16PM +0200, Christian Boos wrote:
Hi all,
I think I've come up with a better way to manage the vc cache.
...
http://projects.edgewall.com/trac/wiki/VcRefactoring#SupportforBigRepositories
I have the feeling that this cached information can be used for
other needs as well:
* next/prev revision for a given path
* implement efficiently the revision graph view (#1445)
I can't really comment on the merits of your proposal, but I note you
mention that "this should also work for mercurial". Shouldn't we be
aiming for cross-VC backend caching as the primary goal? Or perhaps I have
misunderstood? A generic VC caching system seems like very a worthy goal
to me, as anything that simplifies the building of VC backends is going to
help motivate developers provide new backends.
I think we're on the same line here, my comment was to be understood
like this: "this scheme will work for SVN, and should also work for
Mercurial ... let's hope it's good enough for other VCS as well :)".
Hence my request that other people more knowledgeable than me
in other systems have a look at the proposal.
I was also giving some more thought about what the
"next/prev revision" should really mean.
We have basically two options:
1. Follow the global sequence order, skipping revisions irrelevant
for the path. That's what we do currently for SVN.
This *could* also work for Mercurial, where each repository
maintains its own global sequence numbers.
I'm not sure about other VCS.
2. Stay on the branch to which the revision belongs to.
This is not relevant for SVN, as the branch information is tied
to the path and the memory of where that path came from.
But Mercurial and I believe most other systems (even CVS, at the
file level) have the concept of a revision being part of a given
branch.
(1) could easily be optimized and made generic using the new cache.
This would also be more adapted to the current revision log view,
which only consider as special cases the copy/renames.
(2) is the approach I've taken for TracMercurial so far, but I'm
not sure it's the right approach: as the navigation on a branch
could anyway be achieved by following the parents/children links,
maybe it's better to keep prev/next as a way to navigate the global
sequence...
Then, we certainly need to think about an alternate revision log view
more suited to branch-oriented VCS, a kind of gitk/hgk in a browser :)
-- Christian
_______________________________________________
Trac-dev mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-dev
