Version Control Refactoring

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

The forthcoming changes aim to be better support some advanced version control system backends, like ​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@3323//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 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 ​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 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:

1. 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
2. base_path should be left empty when it doesn't change, even for regular edits. This will save some space.
3. 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).