view release on metacpan or  search on metacpan

src/subversion/doc/user/lj_article.txt  view on Meta::CPAN

--> The client libraries.

On the client side, the Subversion "working copy" library maintains
administrative information within special SVN/ subdirectories, similar
in purpose to the CVS/ administrative directories found in CVS working
copies.

A glance inside the typical SVN/ directory turns up a bit more than
usual, however.  The `entries' file contains XML which describes the
current state of the working copy directory (and which basically
serves the purposes of CVS's Entries, Root, and Repository files
combined).  But other items present (and not found in CVS/) include
storage locations for the versioned "properties" (the metadata
mentioned in 'Subversion Features' above) and private caches of
pristine versions of each file.  This latter feature provides the
ability to report local modifications -- and do reversions --
*without* network access.  Authentication data is also stored within
SVN/, rather than in a single .cvspass-like file.

The Subversion "client" library has the broadest responsibility; its
job is to mingle the functionality of the working-copy library with
that of the repository-access library, and then to provide a
highest-level API to any application that wishes to perform general
version control actions.

For example: the C routine `svn_client_checkout()' takes a URL as an
argument.  It passes this URL to the repository-access library and
opens an authenticated session with a particular repository.  It then
asks the repository for a certain tree, and sends this tree into the
working-copy library, which then writes a full working copy to disk
(SVN/ directories and all.)

The client library is designed to be used by any application.  While
the Subversion source code includes a standard command-line client, it
should be very easy to write any number of GUI clients on top of the
client library.  Hopefully, these GUIs should someday prove to be much
better than the current crop of CVS GUI applications (the majority of
which are no more than fragile "wrappers" around the CVS command-line
client.)

In addition, proper SWIG bindings (www.swig.org) should make
the Subversion API available to any number of languages:  java, perl,
python, guile, and so on.  In order to Subvert CVS, it helps to be
ubiquitous! 


Subversion's Future
-------------------

The release of Subversion 1.0 is currently planned for early 2002.
After the release of 1.0, Subversion is slated for additions such as
i18n support, "intelligent" merging, better "changeset" manipulation,
client-side plugins, and improved features for server administration.
(Also on the wishlist is an eclectic collection of ideas, such as
distributed, replicating repositories.)

A final thought from Subversion's FAQ:

   "We aren't (yet) attempting to break new ground in SCM systems, nor
   are we attempting to imitate all the best features of every SCM
   system out there.  We're trying to replace CVS."

If, in three years, Subversion is widely presumed to be the "standard"
SCM system in the open-source community, then the project will have
succeeded.   But the future is still hazy:  ultimately, Subversion
will have to win this position on its own technical merits.

Patches are welcome.


For More Information
--------------------

Please visit the Subversion project website at
http://subversion.tigris.org.  There are discussion lists to join, and
the source code is available via anonymous CVS -- and soon through
Subversion itself.