Hi Christian, > 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...
OK, not a problem. I'm running a 0.10.3 on my server now but I could use 0.11dev for development. > 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). I actually thought some of this could be moved from the ui to the backend (base-class implementation for example). > ... 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. I think I know what you mean... I'll think about what can/makes sense to be cached and what not. I'll post some thought once I could say more on the topic. Regards, Peter --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
