Alien-SVN

 view release on metacpan or  search on metacpan

src/subversion/CHANGES  view on Meta::CPAN

(19 Jun 2008, from /branches/1.5.x)
http://svn.apache.org/repos/asf/subversion/tags/1.5.0

 User-visible changes:
  - Major new features:
    * Merge Tracking [foundational] (issue #820)
    * Sparse checkouts (see new '--depth' option) (issue #695)
    * Interactive conflict resolution (r25670 et al)
    * svn:externals handles relative URLs (issue #1336) and peg URLs
    * Changelist support
    * WebDAV transparent write-through proxy
    * Better support for large FSFS deployments (via sharding & partitioning)
    * Cyrus SASL support for ra_svn and svnserve (issue #1144)

  - Minor new features and improvements:
    * 'svn resolve' (with '--accept' option) replaces "resolved" (issue #2784)
    * 'svn move file1 file2 ... dir' now moves the files into dir (issue #747)
    * 'svn mkdir' and 'svn copy' now take '--parents' option (issue #1776)
    * 'svn delete' now takes '--keep-local' to not remove working copy files
    * 'svn copy', 'move' now support peg revisions (issue #2546; also r26484)
    * 'svn copy A B ; svn move B C' now the same as 'svn copy A C' (issue #756)

src/subversion/doc/doxygen.conf  view on Meta::CPAN

# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the
# graphs generated by dot. A depth value of 3 means that only nodes reachable
# from the root by following a path via at most 3 edges will be shown. Nodes
# that lay further from the root node will be omitted. Note that setting this
# option to 1 or 2 may greatly reduce the computation time needed for large
# code bases. Also note that the size of a graph can be further restricted by
# DOT_GRAPH_MAX_NODES. Using a depth of 0 means no depth restriction.

MAX_DOT_GRAPH_DEPTH    = 0

# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent
# background. This is disabled by default, because dot on Windows does not
# seem to support this out of the box. Warning: Depending on the platform used,
# enabling this option may lead to badly anti-aliased labels on the edges of
# a graph (i.e. they become hard to read).

DOT_TRANSPARENT        = NO

# Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output
# files in one run (i.e. multiple -o and -T options on the command line). This
# makes dot run faster, but since only newer versions of dot (>1.8.10)

src/subversion/subversion/libsvn_fs_base/dag.h  view on Meta::CPAN

   self-consistent set of invariants to maintain, making it
   (hopefully) a useful interface boundary.

   In other words:

   - The dag_node_t interface exposes the internal DAG structure of
     the filesystem, while the svn_fs.h interface does any cloning
     necessary to make the filesystem look like a tree.

   - The dag_node_t interface exposes the existence of copy nodes,
     whereas the svn_fs.h handles them transparently.

   - dag_node_t's must be explicitly cloned, whereas the svn_fs.h
     operations make clones implicitly.

   - Callers of the dag_node_t interface use Berkeley DB transactions
     to ensure consistency between operations, while callers of the
     svn_fs.h interface use Subversion transactions.  */


/* Initializing a filesystem.  */

src/subversion/subversion/libsvn_fs_base/notes/structure  view on Meta::CPAN

reps-strings.c
                Retrieval and storage of represented strings.
                This will handle delta-based storage,

dag.c           Operations on the DAG filesystem.  "DAG" because the
                interface exposes the filesystem's sharing structure.
                Enforce inter-record consistency.

tree.c          Operations on the tree filesystem.  This layer is
                built on top of dag.c, but transparently distinguishes
                virtual copies, making the underlying DAG look like a
                real tree.  This makes incomplete transactions behave
                like ordinary mutable filesystems.

delta.c         Computing deltas.



Appendix: Filesystem structure summary
======================================

src/subversion/subversion/libsvn_fs_fs/dag.h  view on Meta::CPAN

   self-consistent set of invariants to maintain, making it
   (hopefully) a useful interface boundary.

   In other words:

   - The dag_node_t interface exposes the internal DAG structure of
     the filesystem, while the svn_fs.h interface does any cloning
     necessary to make the filesystem look like a tree.

   - The dag_node_t interface exposes the existence of copy nodes,
     whereas the svn_fs.h handles them transparently.

   - dag_node_t's must be explicitly cloned, whereas the svn_fs.h
     operations make clones implicitly.

   - Callers of the dag_node_t interface use Berkeley DB transactions
     to ensure consistency between operations, while callers of the
     svn_fs.h interface use Subversion transactions.  */


/* Generic DAG node stuff.  */

src/subversion/subversion/libsvn_subr/gpg_agent.c  view on Meta::CPAN

 * a running gpg-agent. In contrast to other password store providers
 * it does not save the password to disk.
 *
 * Prompting is performed by the gpg-agent using a "pinentry" program
 * which needs to be installed separately. There are several pinentry
 * implementations with different front-ends (e.g. qt, gtk, ncurses).
 *
 * The gpg-agent will let the password time out after a while,
 * or immediately when it receives the SIGHUP signal.
 * When the password has timed out it will automatically prompt the
 * user for the password again. This is transparent to Subversion.
 *
 * SECURITY CONSIDERATIONS:
 *
 * Communication to the agent happens over a UNIX socket, which is located
 * in a directory which only the user running Subversion can access.
 * However, any program the user runs could access this socket and get
 * the Subversion password if the program knows the "cache ID" Subversion
 * uses for the password.
 * The cache ID is very easy to obtain for programs running as the same user.
 * Subversion uses the MD5 of the realmstring as cache ID, and these checksums

src/subversion/subversion/libsvn_wc/ambient_depth_filter_editor.c  view on Meta::CPAN

     about the "ambient depth" of each working copy directory.

     For example, suppose a 1.5 client does this against a 1.4 server:

       $ svn co --depth=empty -rSOME_OLD_REV http://url/repos/blah/ wc
       $ cd wc
       $ svn up

     In the initial checkout, the requested depth is 'empty', so the
     depth-filtering editor (see libsvn_delta/depth_filter_editor.c)
     that wraps the main update editor transparently filters out all
     the unwanted calls.

     In the 'svn up', the requested depth is unspecified, meaning that
     the ambient depth(s) of the working copy should be preserved.
     Since there's only one directory, and its depth is 'empty',
     clearly we should filter out or render no-ops all editor calls
     after open_root(), except maybe for change_dir_prop() on the
     top-level directory.  (Note that the server will have stuff to
     send down, because we checked out at an old revision in the first
     place, to set up this scenario.)

src/subversion/subversion/mod_dav_svn/mirror.c  view on Meta::CPAN

/*
 * mirror.c: Use a transparent proxy to mirror Subversion instances.
 *
 * ====================================================================
 *    Licensed to the Apache Software Foundation (ASF) under one
 *    or more contributor license agreements.  See the NOTICE file
 *    distributed with this work for additional information
 *    regarding copyright ownership.  The ASF licenses this file
 *    to you under the Apache License, Version 2.0 (the
 *    "License"); you may not use this file except in compliance
 *    with the License.  You may obtain a copy of the License at
 *

src/subversion/subversion/tests/cmdline/tree_conflict_tests.txt  view on Meta::CPAN

                               -*- text -*-

                     TREE CONFLICT TESTING STRATEGY


This document describes how we are testing the code that detects,
reports and resolves tree conflicts.  We'd like to make the testing,
and the tree conflicts feature itself, more transparent and open to
contributions.

For tree conflicts, there already exist cmdline tests for the update,
switch, merge, commit, status, info and revert commands.  We've added
tree_conflicts_tests.py, not to replace the other tests, but rather to
complement them by offering a generic way to create lots of
tree-conflict detection test scenarios.  The generic framework is not
yet finished, but we think it will be useful as we extend the
tree-conflict feature beyond its original use cases.