Future
******

Here are some thoughts on features to include in later releases of Subversion.

High Priority Items
===================

These are things that should be released in Subversion 1.0, if we really want to achieve the goal of creating a compelling replacement for CVS.

The lists below are a bit dated;  a more recent wishlist can be found in IDEAS in the source-tree.

Annotation
----------

We need to provide annotation of individual files (i.e. who wrote which line in which revision), because CVS does this reasonably well.

The information needed to annotate files should be stored by the filesystem as properties.

The ``annotate'' method itself should be implemented as a server-side plug-in.  This makes the output much more hackable.

Repository Conversion
---------------------

We need to write a tool which will convert a CVS repository into an SVN repository, preserving all history.  This is absolutely critical in persuading people to switch to SVN.

Bob Miller <kbob@jogger-egg.com> has already started work on this tool, which can be found in tools/cvs2svn/.

User Interface for Branches and Tags
------------------------------------

This is a tricky issue.

The Subversion Filesystem implements branches and tags by using ``clones'';  both branches and tags appear as ordinary directories in the filesystem.

We have been told that this implementation is quite confusing for end-users.  (The closed-source version-control system Perforce uses this method.)  It's apparently confusing, when browsing the filesystem, to know which subdirectories represents the main-lines of a project, and which represent branches or tags.  This problem is made worse by users accidentally (or carelessly) creating clone directories in bad places, such as inside the trees they're cloning.

There are a number of proposed solutions being discussed.  They all center on two principles:

  * Recommending a repository filesystem structure that cleanly divides trunks, branches, and tags;

  * Implementing client behavior that ``hides'' this repository structure from the end user, and allows them to continue using intuitive branch and tag commands.

Blue Sky Items
==============

These are features we'd like to see in Subversion someday, but aren't critical for a 1.0 release.

Server Grep
-----------

Write a server-side plug-in which can quickly search a filesystem's text and properties.

Scripting Language
------------------

Write a server-side plug-in which provides glue between svn_main and libguile.so, libperl.so, or libpython.so.  The server becomes very extensible if it has an interpreted language built into it; it's also very nice for writing test suites!

Smart conflict resolution
-------------------------

Certain kinds of conflicts can be resolved without human intervention. For example, files like /etc/passwd just need to keep lines unique by username and user ID.

Right now, merging new repository data into a modified working copy of a passwd file can result in a textual conflict even when there's no "semantic conflict".  But if the Subversion client knew something about the format of passwd files, then it could merge without flagging a conflict.

A similar rule could be used for ChangeLogs, based on the dates in the header lines.  And so on.

Since all merging takes place on the client, these ``smart merges'' should be implemented as a client-side plug-in.

Mirroring Servers
-----------------

This is like the ClearCase multisite feature.  Essentially, it is a redundant distributed repository.  The repository exists on two or more cooperatively mirroring servers (each one presumably being close, network-wise, to its intended users).  A commit from any user is visible on all the servers.

The best way to implement this is by creating a ``hierarchy'' of Subversion servers, much like the DNS or NIS system.  We can define a server master to contain the ``authoritative'' repository.  We can then set up any number of slave servers to mirror the master.  The slave servers exist primarily as local caches; it makes reads and updates faster for geographically disperse users.  When a user wishes to commit, however, her delta is always sent to the master server.  After the master accepts the change, the delta is automatically ``pushed'' out to the caching slave servers.

Inter-Repository Communication
------------------------------

This is one that people request a lot: the ability to commit changes first to a local "working repository" (not visible to the rest of the world), and then commit what's in the working repository to the real repository (with the several commits maybe being folded into one commit).

Why do people want this?  It may be the psychological comfort of making a snapshot whenever one reaches a good stopping point, but not necessarily wanting all those ``comfort points'' to become publically-visible commits.

The best way to implement this is to allow ``clones'' to cross between repositories. (see Bubble-Up Method.)

In other words, Joe Hacker sets up a personal Subversion repository on his desktop machine; he creates a local ``clone'' of a subtree from a public repository.  He commits to his clone (which turns it into a branch), and when he's done, he performs a branch-merge back into the public repository.

SQL Back-End
------------

The initial release of the Subversion filesystem will use Berkeley DB to store data on disk. However, in the future, a SQL database may be used to add sophisticated query support across the filesystem (e.g. "what revisions of what files has property xyz?").

To support this feature, Someone could rewrite the filesystem back-end to speak SQL, in addition to the default Berkeley DB support.

Digital Signatures
------------------

A few people have mentioned cryptographic signing of deltas.  It's a cool idea, and we should leave the door open for it.

Import/Export format
--------------------

Suggested by Jason Robbins; he mentioned this as a nice thing to have someday.  It makes repositories easy to transport.

Subversion already has an XML DTD that it uses for testing updates and commits;  this DTD may be 80% of the "exchange" format we're looking for.

SMTP access
-----------

Write a totally independent Network Layer which is an SMTP server on one end, and speaks to the Subversion server library on the back end.  It would be neat to be able to "mail in" commits, or receive working-copy updates through e-mail.