Edgewall Software

Changes between Version 9 and Version 10 of VcRefactoring


Ignore:
Timestamp:
Feb 7, 2007, 12:26:00 PM (17 years ago)
Author:
Christian Boos
Comment:

Update the targeted milestone to 0.12 and add some multi-project support considerations

Legend:

Unmodified
Added
Removed
Modified

  • VcRefactoring

    v9 v10  
    3131== Support for Multiple Repositories ==
    3232
    33 This will be done for [milestone:0.11].
    34 
    35 The cache needs to be modified/extended as well.
     33This will most likely have to wait [milestone:0.12].
     34
     35The cache needs to be modified/extended as well,
     36in order to accommodate multiple repositories.
     37
    3638There are several options:
    3739 1. use the cache as it is, merging all the repositories in a kind of virtual repository;
    … …  
    4042 3. use a dedicated db to cache each repository
    4143
    42 1. seems the easiest way to go, not sure if it will be the most efficient, though.
     44Option 1. seems the best way to go.
     45Its efficiency depends mainly about how the new cache will be implemented.
     46If we go with path ids, then using one table would be practical, I think.
    4347
    4448See also: #2086, trac-dev:340 and, more recently, [googlegroups:trac-users:14ca95377e4a53b5 this mail] where I explain how TracLinks will support multiple repositories.
    4549
     50Another important interdependency which comes to mind is the support for multiple projects in a single environment (see this
     51[TracMultipleProjects/SingleEnvironment#ProposedImplementation proposal]).
     52
     53In this scenario, each project would have one or more repositories.
     54Those repositories could eventually be ''shared'' between projects.
     55
     56Take the following example:
     57 - Project A
     58   - repository /srv/svn/repo1 (trunk, branches, etc.)
     59 - Project B
     60   - repository /srv/svn/repo1 (trunk, branches, etc.)
     61   - repository /srv/svn/repo2 (trunk, branches, etc.)
     62
     63Within 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/`.
     64
     65Now within project B, referring to `[123]` or `source:trunk/` would be ambiguous,
     66unless a ''default'' repository would be specified (say /srv/svn/repo2).
     67But in general, ''path restriction'' should be used to properly identify the resource:
     68`[123/repo1]`, `source:repo1/trunk/` and `[123/repo2]`, `source:repo2/trunk/`.
     69
     70The ''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:
     71 - this shouldn't happen often in the first place
     72 - if it happens nevertheless, a simple disambiguation rule could be adopted,
     73   like always consider that if the first element in the path restriction
     74   corresponds to a repository name when multiple repositories are present,
     75   then it's used as a repository selector.
     76
     77On 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.
    4678
    4779== Support for Mercurial-like Version Control System ==
    … …  
    5486     * support for SVN: see #2545
    5587
    56 Those are the minimal changes needed so that the Mercurial plugin can work at all.
     88Those are the minimal changes needed so that the TracMercurial plugin can work at all.
    5789
    5890
    5991=== Advanced Level ===
    6092
    61  * Support for direct jump to a tag or a branch.
    62    Done on the branch (r3017); not yet ported to trunk.
    6393 * TracRevisionLog should show the branches (a la
    64    [http://www.flickr.com/photos/search/tags:mercurial%2Chgk/tagmode:all/ hgk])
     94   [http://www.flickr.com/photos/search/tags:mercurial%2Chgk/tagmode:all/ hgk]).
     95   See also #1492.
    6596 * DONE:
    6697   * Support for arbitrary changeset names (e.g. `[tip]` or `[head]`)
    67 
     98   * Support for direct jump to a tag or a branch.
     99     Done on the branch (r3017); re-done for 0.11 (now in trunk)
    68100
    69101=== Support for Big Repositories ===
    … …  
    73105the caching anyway.
    74106
    75 This is material for Trac [milestone:0.11]
     107This is material for Trac [milestone:0.12]...
    76108
    77109== New Repository Cache ==
    … …  
    80112be able to handle this. The idea is to replicate the tree
    81113changes information that svn stores. This should also work
    82 for mercurial or other backends.
     114for Mercurial or other backends.
    83115
    84116The `node_changes` table could even be kept as it is, I think.
    … …  
    88120that has been modified.
    89121
    90 That way, we could efficiently implement `Repository.get_nodes(path, rev)`
    91 using the cached information only.
    92 `Repository.get_path_history`
    93 could also be implemented in a generic and efficient way using that
    94 caching scheme.
    95 
    96 ''As a side note, `Repository.get_changes(from,to)` should also
    97 be implemented using the cached information in the `revision`
    98 table (that would solve the #2353 issue).''
     122That way, we could implement:
     123 - `Repository.get_node(path, rev)` using the cached information only,
     124   which would be a dramatic improvement for Mercurial, which has no
     125   information about the folder themselves.
     126 - Likewise, `Repository.get_path_history` could also be implemented
     127   in a generic and efficient way using that caching scheme.
     128 - The next/prev history navigation between revisions (or rather,
     129   their extended children/parents versions) could also be implemented
     130   on top of the cache.
     131 - Probably `Node.get_history` as well, not to mention the possibility
     132   to find out the ''copy_to'' information (#1445).
     133 - `Repository.get_changes(from,to)` should also be implemented
     134   using the cached information in the `revision` table
     135   (that would solve the #2353 issue).
     136
    99137
    100138Example:
    … …  
    148186    i.e. the latest revision in which its ''change_type'' was not null.
    149187
     188The paths could maybe be represented by hashes of their dirname,
     189and only the filename part would be in clear text (#3676?).
    150190
    151191
    … …  
    153193in particular the file size. Using Mercurial:RevlogNG, that
    154194information would be cheap to get, but revlogng is not yet
    155 widely used.
     195widely used. -- ''update: source:sandbox/mercurial-plugin-0.11 uses the new API''
    156196
    157197The most flexible approach for storing extra node fields is certainly
    158198to let each backend create and maintain an additional table,
    159199e.g. `node_changes_hg` (see also #2733).
     200
     201----
     202
     203See also: [googlegroups:trac-dev:f32afb39eb3bfd87 improving bazaar support], discussed on Trac-Dev