= Version Control Refactoring = This recurring topic is the place to discuss the design of new features for the **version control** subsystem of Trac. [[PageOutline]] Some of the major goals are: 1. ~~support for multiple repositories~~ 2. support for scm neutral cache 3. ideally, if the GenericTrac approach is finalized, arbitrary properties, comments and attachments for changeset and path Trac resources (useful for code reviews) The forthcoming changes aim to better support some advanced version control system backends, like [http://www.selenic.com/mercurial Mercurial] and [http://git-scm.org git], while not (completely) forgetting [http://subversion.apache.org Subversion] (yet). To that effect, the changes added to the core will be exercised by jointly developing the TracMercurial plugin and probably the GitPlugin as well (see in [source:plugins]). Sub topics: [[TitleIndex(VcRefactoring/)]] - Initial Mercurial support - [./@15#SupportforMercurial-likeVersionControlSystem] - MultiRepos - see source:sandbox/multirepos and [./@15#SupportforMultipleRepositories] == New Repository Cache == A new cache should be designed with the primary focus on achieving maximal performance for the tasks needed by the TracBrowser. The current cache simply contains the required information, but not organized in a way that can speed-up by indexes for the common tasks. The primary example for this is the prev_next_rev queries. The second example would be the get_entries() call which is expensive for TracMercurial and TracGit. The other constraints would be: - `Repository.get_node(path, rev)` using the cached information only, which would be a dramatic improvement for Mercurial, which has no information about the folder themselves. - `Repository.get_path_history` could also be implemented in a generic and efficient way using that caching scheme. This would also help address #10183 and #7744. - The next/prev history navigation between revisions (or rather, their extended children/parents versions) could also be implemented on top of the cache (#8639; #7254; ticket:8813#comment:10) - Probably `Node.get_history` as well, not to mention the possibility to find out the ''copy_to'' information (#1445). - `Repository.get_changes(from,to)` should also be implemented using the cached information in the `revision` table (that would solve the #2353 issue). === `node_change` + directories One idea would be to keep the `node_change` table as it is but we should also add the paths for files and folders that were not modified themselves, but happen to be in the same folder as one of the file or folder that has been modified. Example: {{{ (1) trunk/ (2) trunk/ (3) trunk/ (4) trunk/ (5) trunk/ dir1/ dir1/ dir1/ ... ... dir2/ dir2/ dir2/ tags/ tags/ README README* README v1/ (copied from trunk) dir3/ dir3/ A A* B B }}} Would result in: ||= rev ||= path ||= node_type ||= change_type ||= base_path ||= base_rev || || 1 || trunk || D || A || || -1 || || 1 || trunk/dir1 || D || A || || -1 || || 1 || trunk/dir2 || D || A || || -1 || || 1 || trunk/README || F || A || || -1 || || || || || || || || || 2 || trunk || D || ''(i)'' || ''(ii)'' || 2 ''(iii)'' || || 2 || trunk/dir1 || D || || || 1 || || 2 || trunk/dir2 || D || || || 1 || || 2 || trunk/README || F || E || || 1 || || 2 || trunk/dir3 || D || A || || -1 || || 2 || trunk/dir3/A || F || A || || -1 || || 2 || trunk/dir3/B || F || A || || -1 || || || || || || || || || 3 || trunk || D || || || 3 || || 3 || trunk/dir1 || D || || || 1 || || 3 || trunk/dir2 || D || || || 1 || || 3 || trunk/README || F || || || 2 || || 3 || trunk/dir3 || D || || || 3 || || 3 || trunk/dir3/A || F || E || || 2 || || 3 || trunk/dir3/B || F || || || 2 || || || || || || || || || 4 || trunk || D || || || 3 || || 4 || tags || D || A || || -1 || || || || || || || || || 5 || trunk || D || || || 3 || || 5 || tags || D || || || 5 || || 5 || tags/v1 || D || C || trunk || 3 || Notes: i. ''change_type'' will be empty when the path didn't actually change in that revision, but is simply included in the cache for the sake of `get_nodes` ii. ''base_path'' should be left empty when it doesn't change, even for regular edits. This will save some space. iii. ''base_rev'' will point to the last changed rev for that path, i.e. the latest revision in which its ''change_type'' was not null. The paths could maybe be represented by hashes of their dirname, and only the filename part would be in clear text (#3676?). The most flexible approach for storing extra node fields is certainly to let each backend create and maintain an additional table, e.g. `node_changes_hg` (see also #2733). In addition, there will most certainly be the need for a kind of `revision_link` table in the general case, listing the prev/next relations between revisions. Of course, a backend which only needs a sequential ordering for its revisions should be able to bypass that table. ---- See also: the original Trac-Dev:161 thread, [googlegroups:trac-dev:f32afb39eb3bfd87 improving bazaar support] on Trac-Dev