| 27 | | The current controller changes are simple refactorings which are not changing the versioncontrol API, but cleaning up the internals of the versioncontrol related web ui. |
| 28 | | Those changes could eventually go in 0.11. |
| 29 | | |
| 30 | | |
| 31 | | == Support for Multiple scopes within a Repository == |
| 32 | | |
| 33 | | This is mostly done in trunk, now. |
| 34 | | * This basically means fixing #1830. Initial work on this was done in r2992. |
| 35 | | This has been reworked more in-depth in [3174/trunk/trac/versioncontrol/svn_fs.py]. |
| 36 | | * There's also the idea to "scope" a repository using multiple paths. |
| 37 | | This will probably be done for milestone:0.11. |
| 38 | | Actually, it should be possible to achieve the above using FineGrainedPermissions, |
| 39 | | thanks to r3174, but I haven't verified this, up to now. |
| 40 | | |
| 41 | | |
| 42 | | == Support for Multiple Repositories == |
| 43 | | |
| 44 | | A first implementation of this feature is now available in the MultipleRepositorySupport branch (for the next release, i.e. Trac [milestone:0.12]). |
| 45 | | |
| 46 | | The problematic of the cache is for now avoided, this multiple repository support is only for the non-cached repositories, i.e. `hg` (Mercurial) and `direct-svnfs` (Subversion). You can happily mix ''both'' types of repositories, if needed. |
| 47 | | |
| 48 | | The cache needs to be modified/extended as well, |
| 49 | | in order to accommodate multiple repositories. |
| 50 | | |
| 51 | | There are several options: |
| 52 | | 1. use the cache as it is, merging all the repositories in a kind of virtual repository; |
| 53 | | the first component of the path would be the name of the repository. |
| 54 | | 2. use a separate pair of tables for each repository |
| 55 | | 3. use a dedicated db to cache each repository |
| 56 | | |
| 57 | | Option 1. seems the best way to go. |
| 58 | | Its efficiency depends mainly about how the new cache will be implemented. |
| 59 | | If we go with path ids, then using one table would be practical, I think. |
| 60 | | |
| 61 | | See also: #2086, trac-dev:340 and, more recently, [googlegroups:trac-users:14ca95377e4a53b5 this mail] where I explain how TracLinks will support multiple repositories. |
| 62 | | |
| 63 | | Another important interdependency which comes to mind is the support for multiple projects in a single environment (see this |
| 64 | | [TracMultipleProjects/SingleEnvironment#ProposedImplementation proposal]). |
| 65 | | |
| 66 | | In this scenario, each project would have one or more repositories. |
| 67 | | Those repositories could eventually be ''shared'' between projects. |
| 68 | | |
| 69 | | Take the following example: |
| 70 | | - Project A |
| 71 | | - repository /srv/svn/repo1 (trunk, branches, etc.) |
| 72 | | - Project B |
| 73 | | - repository /srv/svn/repo1 (trunk, branches, etc.) |
| 74 | | - repository /srv/svn/repo2 (trunk, branches, etc.) |
| 75 | | |
| 76 | | Within a wiki page of project A, `[123]` or `source:trunk/` would have the usual 1-to-1 meaning. The same resources, referenced from within a page belonging to project B could be accessed using InterTrac links: `[A123]` or `A:source:trunk/`. |
| 77 | | |
| 78 | | Now within project B, referring to `[123]` or `source:trunk/` would be ambiguous, |
| 79 | | unless a ''default'' repository would be specified (say /srv/svn/repo2). |
| 80 | | But in general, ''path restriction'' should be used to properly identify the resource: |
| 81 | | `[123/repo1]`, `source:repo1/trunk/` and `[123/repo2]`, `source:repo2/trunk/`. |
| 82 | | |
| 83 | | ''How about `[123@repo2]`, `source:@repo2/trunk` and let `[source:trunk]` go to the default repository of the project so that when a new repository is added to the project, all existing links won't break?''[[br]]''-- Kenneth Xu'' |
| 84 | | |
| 85 | | The ''only'' problem with this approach would be to risk some confusion if a repository name is also used as a toplevel folder name of some other repository in the same project. I'm don't think it's a showstopper though, as: |
| 86 | | - this shouldn't happen often in the first place |
| 87 | | - if it happens nevertheless, a simple disambiguation rule could be adopted, |
| 88 | | like always consider that if the first element in the path restriction |
| 89 | | corresponds to a repository name when multiple repositories are present, |
| 90 | | then it's used as a repository selector. |
| 91 | | |
| 92 | | On the data model level, the cache for /srv/svn/repo1 will be shared for projects A and B. We simply need an additional relation table, pairing projects with repositories. |
| 93 | | |
| 94 | | == Support for Mercurial-like Version Control System == |
| 95 | | |
| 96 | | === Basic Level === |
| 97 | | * DONE: |
| 98 | | * support for non-numerical changesets (start with hexadecimal digit support) |
| 99 | | * support for extra changeset properties |
| 100 | | * basic infrastructure in trunk |
| 101 | | * support for SVN: see #2545 |
| 102 | | |
| 103 | | Those are the minimal changes needed so that the TracMercurial plugin can work at all. |
| 104 | | |
| 105 | | |
| 106 | | === Advanced Level === |
| 107 | | |
| 108 | | * TracRevisionLog should show the branches (a la |
| 109 | | [http://www.flickr.com/photos/search/tags:mercurial%2Chgk/tagmode:all/ hgk]). |
| 110 | | See also #1492. |
| 111 | | * DONE: |
| 112 | | * Support for arbitrary changeset names (e.g. `[tip]` or `[head]`) |
| 113 | | * Support for direct jump to a tag or a branch. |
| 114 | | Done on the branch (r3017); re-done for 0.11 (now in trunk) |
| 115 | | |
| 116 | | === Support for Big Repositories === |
| 117 | | |
| 118 | | This means extending cache support. |
| 119 | | Support for multiple repositories would also require some changes to |
| 120 | | the caching anyway. |
| 121 | | |
| 122 | | This is material for Trac [milestone:0.12]... |
