Christopher Lenz wrote:
Am 07.02.2006 um 12:09 schrieb Christian Boos:
The items I want to address this time are:
* fixing #1830 (Repository subsets have to be fully self contained)
For this, I think returning 'None' in place where we used
to raise a 'TracError: no such changeset or no such node'
would be enough. Of course, many places in the code would
have to be adapted to handle this situation, so I guess this
is potentially disruptive.
So basically you just check for None instead of catching an exception?
Yes, that's what I was thinking of. However, it's maybe not that critical
and maybe catching a few exceptions could be enough.
I've to actually code it to tell :)
On a related note, we really need more specific exception types in the
versioncontrol layer, like:
* NodeNotFound
* RevisionNotFound
That would be another possibility.
* etc (others?)
* ...
Tag and branch support in svn could be added by using a
[subversion] configuration section, where tags and branches
could be listed (defaults would be e.g. tags/* and branches/*).
I'd omit the SVN stuff for now and just provide tags/branches support
for those repository types that have a tag/branch dimension that is
separate from the directory structure.
Ok.
...
Then, some more important changes:
* rework the interaction with the cache.
...
* for the Node information (currently not used, but would
be crucial for "flat" versioning systems like mercurial)
Can you please elaborate on that last point?
I said Mercurial is "flat" as opposed to "hierarchical" like SVN is,
in that it doesn't reflect the file system hierarchy in its datastructures:
there's no equivalent to a "Node", there's even no support for
directories. There's only a list of (all) files in the project, the
"manifest".
So basically emulating an hg Node in Trac requires some work, e.g. see
http://projects.edgewall.com/trac/browser/sandbox/mercurial-plugin/hgtrac/hg.py?rev=2646#L336
That's OK for a project like Mercurial or even Trac, but for very large
projects, like the Linux kernel, for which Mercurial is designed, it makes
it impractical.
So here, the solution would be to reconstruct a node from the cache,
and that can't be done in a "generic" way, I think.
For that, the cache architecture has to become a bit more apparent to
the backend that needs it. Darcs and bzr backends also need a
more intimate access to the cache, IIRC.
...
Overall, +1
What I'd prefer for the implementation approach would be to order
changes so that those *absolutely required* for *minimal* support for
a VCS such as Mercurial go first (I think this is only cache and
changeset link patterns). Those
The cache is only absolutely required for huge, "kernel"-sized repositories,
otherwise it works already pretty well without.
The absolutely required changes are the changeset link patterns,
and the additional changeset properties, because we must support
multiple parents and/or children, that is, multiple ''prev'' or ''next''
revisions.
changes that are needed for *good* support for Mercurial/etc go next.
That would be the tag and branch support.
Plus we should try to get feedback from the folks who worked on
Darcs/BazaarNG/Perforce support.
Yep.
-- Christian
_______________________________________________
Trac-dev mailing list
Trac-dev@lists.edgewall.com
http://lists.edgewall.com/mailman/listinfo/trac-dev
