= Version Control Refactoring =

This branch is a sandbox for introducing new features
that are potentially disruptive.

[[PageOutline]]

The forthcoming changes aim to be better support some
advanced version control system backends, like 
[http://www.selenic.com/mercurial Mercurial].
To that effect, the changes added to the core will be 
exercised by jointly developing the TracMercurial plugin.

Straight from the sandbox:
 * current changes from trunk: diff:trunk@3538//sandbox/vc-refactoring
 * revision log: log:sandbox/vc-refactoring

See also the related Trac-Dev:161 thread.


== Support for Multiple scopes within a Repository ==

This is mostly done in trunk, now.
 * This basically means fixing #1830. Initial work on this was done in r2992.
   This has been reworked more in-depth in [3174/trunk/trac/versioncontrol/svn_fs.py].
 * There's also the idea to "scope" a repository using multiple paths.
   This will probably be done for milestone:0.11.
   Actually, it should be possible to achieve the above using FineGrainedPermissions,
   thanks to r3174, but I haven't verified this, up to now.


== Support for Multiple Repositories ==

This will be done for [milestone:0.11].

The cache needs to be modified/extended as well.
There are several options:
 1. use the cache as it is, merging all the repositories in a kind of virtual repository;
    the first component of the path would be the name of the repository.
 2. use a separate pair of tables for each repository
 3. use a dedicated db to cache each repository

1. seems the easiest way to go, not sure if it will be the most efficient, though.

See also: #2086, trac-dev:340.


== Support for Mercurial-like Version Control System ==

===  Basic Level ===
 * DONE:
   * support for non-numerical changesets (start with hexadecimal digit support)
   * support for extra changeset properties
     * basic infrastructure in trunk 
     * support for SVN: see #2545

Those are the minimal changes needed so that the Mercurial plugin can work at all.


=== Advanced Level === 

 * Support for direct jump to a tag or a branch.
   Done on the branch (r3017); not yet ported to trunk.
 * TracRevisionLog should show the branches (a la 
   [http://www.flickr.com/photos/search/tags:mercurial%2Chgk/tagmode:all/ hgk])
 * DONE:
   * Support for arbitrary changeset names (e.g. `[tip]` or `[head]`)


=== Support for Big Repositories ===

This means extending cache support.
Support for multiple repositories would also require some changes to 
the caching anyway.

This is material for Trac [milestone:0.11]

== New Repository Cache ==

I think I've come up with a new caching scheme that would
be able to handle this. The idea is to replicate the tree 
changes information that svn stores. This should also work
for mercurial or other backends.

The `node_changes` table could even be kept as it is, I think.
The main difference would be that 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.

That way, we could efficiently implement `Repository.get_nodes(path, rev)`
using the cached information only.
`Repository.get_path_history` 
could also be implemented in a generic and efficient way using that 
caching scheme.

''As a side note, `Repository.get_changes(from,to)` should also
be implemented using the cached information in the `revision`
table (that would solve the #2353 issue).''

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.



Mercurial would need to store additional information per node,
in particular the file size. Using Mercurial:RevlogNG, that
information would be cheap to get, but revlogng is not yet 
widely used.

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).