Peter Dimov wrote: > Dear all, > > Attached is a patch based on trac-0.10.3 containing some refactoring to > the versioncontrol module (not the svn backend though). >
Ouch, while it's OK to use 0.10-stable in order to show example code, we can't base further developments on that. The codebase has already evolved significantly in trunk from 0.10-stable; not that much, but enough to make merging painful, I guess. 0.11dev is still a "moving target", but it won't move a lot in the versioncontrol area, so it's relatively safe to hack things there... > Here is a summary of the changes: > > class Repository: > def get_revision(self, path, rev): return Revision > def get_node(self, path, rev): return Node > > class Node: > self.path > self.rev > def get_revision(self): return Revision > def get_history(self, limit, stop_rev):return [Node, ...] > > class Revision: > self.message > self.author > self.date > self.base_path # branch/repository base > def get_node(path): return Node > > I currently have the browser and log almost completely working with the > new interface and the modified trac+bzr plugin but Im still far from ready. > > I see plenty of calls to normalize_rev and normalize_path in the > trac.log. I would like to suggest removing the functions normalize_*. > Sure, now the Revision object *is* the normalization of the rev info. For the path, yes, it could probably be done in the public API methods. > ... > > I really liked Christians suggestion to use > revision.get_changeset(path). The second way of getting a changeset > would be by calling repository.get_changeset(new_node, old_node). > Furthermore, I thought it might make sense to have the Changeset class > ONLY represent the changes (files) but NOT the revision (message, data, > author). Ok. > I feel like a lot of refactoring can be done in > web_ui.changeset and I guess Ill start from there before further > refactoring the versioncontrol api. > So, as I said, better base your changes on 0.11, as if we setup a branch in the future to go on with this approach, it'll be based on trunk, of course. > Looking forward to your comments Last minor point: I've seen that you removed a bunch of the logic regarding show_path_history in log.py. While this code can certainly be cleaned-up, removing it is not the way to go ... better add comments for the suspicious parts (or comment them out). The show_path_history stuff is rather complex in Subversion, I've not even started to implement it in Mercurial. The point is that those things will be quite easy to implement in a cross-vc way once we'll have the new cache. Also, it will be 10x or 100x faster ;) ... which brings me to another point, the main refactoring I planned for 0.12 was to introduce this new cache, in order to speed-up the browsing for distributed vcs like Mercurial. The other points (multi-repository support, new "merge" change kind, parents/children relationship between changesets and DAG-like revision log) must of course be considered while designing and implementing this new cache. But likewise, the new API must also keep in mind the cache, in order to avoid to have to break the API once again. -- Christian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
