doc/future.texi - subversion - Git at Google

 @node Future
 @chapter Future

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

 @menu
 * High Priority Items::
 * Blue Sky Items::
 @end menu

 @c -----------------------------------------------------------------------
 @node High Priority Items
 @section High Priority Items

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


 @menu
 * Annotation::
 * Repository Conversion::
 * User Interface for Branches and Tags::
 @end menu

 @node Annotation
 @subsection Annotation

 We need to provide annotation of individual files (i.e. who wrote which
 line in which version), 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.


 @node Repository Conversion
 @subsection 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.


 @node User Interface for Branches and Tags
 @subsection 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 @emph{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:

 @itemize @bullet
 @item
   Recommending a repository filesystem structure that cleanly divides
   trunks, branches, and tags;
 @item
   Implementing client behavior that ``hides'' this repository structure
 from the end user, and allows them to continue using intuitive branch
 and tag commands.
 @end itemize


 @c -----------------------------------------------------------------------
 @node Blue Sky Items
 @section Blue Sky Items


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


 @menu
 * Server Grep::
 * Scripting Language::
 * Smart conflict resolution::
 * Mirroring Servers::
 * Inter-Repository Communication::
 * SQL Back-End::
 * Digital Signatures::
 * Import/Export format::
 * SMTP access::
 @end menu

 @node Server Grep
 @subsection Server Grep

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


 @node Scripting Language
 @subsection Scripting Language

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


 @node Smart conflict resolution
 @subsection Smart conflict resolution

 Certain kinds of conflicts can be resolved without human intervention.
 For example, files like @file{/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.


 @node Mirroring Servers
 @subsection 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 @dfn{master} to contain the ``authoritative'' repository.  We can
 then set up any number of @dfn{slave} servers to mirror the master.  The
 slave servers exist primarily as local caches; it makes @code{reads} and
 @code{updates} faster for geographically disperse users.  When a user
 wishes to @code{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.


 @node Inter-Repository Communication
 @subsection 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. (@xref{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.


 @node SQL Back-End
 @subsection SQL Back-End

 The Subversion filesystem will probably use Berkeley DB to store data on
 disk; however, a real SQL database provides much more reliable
 transactions.  Someone can rewrite the filesystem back-end to speak SQL.


 @node Digital Signatures
 @subsection 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.


 @node Import/Export format
 @subsection Import/Export format

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


 @node SMTP access
 @subsection 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 neat to be able to "mail in" commits, or receive working-copy
 updates through e-mail.
	@node Future
	@chapter Future

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

	@menu
	* High Priority Items::
	* Blue Sky Items::
	@end menu

	@c -----------------------------------------------------------------------
	@node High Priority Items
	@section High Priority Items

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


	@menu
	* Annotation::
	* Repository Conversion::
	* User Interface for Branches and Tags::
	@end menu

	@node Annotation
	@subsection Annotation

	We need to provide annotation of individual files (i.e. who wrote which
	line in which version), 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.


	@node Repository Conversion
	@subsection 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.


	@node User Interface for Branches and Tags
	@subsection 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 @emph{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:

	@itemize @bullet
	@item
	Recommending a repository filesystem structure that cleanly divides
	trunks, branches, and tags;
	@item
	Implementing client behavior that ``hides'' this repository structure
	from the end user, and allows them to continue using intuitive branch
	and tag commands.
	@end itemize


	@c -----------------------------------------------------------------------
	@node Blue Sky Items
	@section Blue Sky Items


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


	@menu
	* Server Grep::
	* Scripting Language::
	* Smart conflict resolution::
	* Mirroring Servers::
	* Inter-Repository Communication::
	* SQL Back-End::
	* Digital Signatures::
	* Import/Export format::
	* SMTP access::
	@end menu

	@node Server Grep
	@subsection Server Grep

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


	@node Scripting Language
	@subsection Scripting Language

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


	@node Smart conflict resolution
	@subsection Smart conflict resolution

	Certain kinds of conflicts can be resolved without human intervention.
	For example, files like @file{/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.


	@node Mirroring Servers
	@subsection 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 @dfn{master} to contain the ``authoritative'' repository. We can
	then set up any number of @dfn{slave} servers to mirror the master. The
	slave servers exist primarily as local caches; it makes @code{reads} and
	@code{updates} faster for geographically disperse users. When a user
	wishes to @code{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.


	@node Inter-Repository Communication
	@subsection 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. (@xref{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.


	@node SQL Back-End
	@subsection SQL Back-End

	The Subversion filesystem will probably use Berkeley DB to store data on
	disk; however, a real SQL database provides much more reliable
	transactions. Someone can rewrite the filesystem back-end to speak SQL.


	@node Digital Signatures
	@subsection 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.


	@node Import/Export format
	@subsection Import/Export format

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


	@node SMTP access
	@subsection 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 neat to be able to "mail in" commits, or receive working-copy
	updates through e-mail.