RubyGems - svnauto - Versions diffs - 1.0.2 → 1.1.0 - Mend

svnauto 1.0.2 → 1.1.0

Files changed (40) hide show

data/bin/sc +2 -10
data/{lib/sc/constants.rb → bin/sva} +8 -13
data/lib/{sc.rb → svnauto.rb} +13 -9
data/lib/{sc → svnauto}/command.rb +8 -3
data/lib/{sc → svnauto}/commands/bug.rb +5 -2
data/lib/{sc → svnauto}/commands/checkout.rb +3 -1
data/lib/{sc → svnauto}/commands/config.rb +18 -2
data/lib/{sc → svnauto}/commands/create.rb +2 -1
data/lib/{sc → svnauto}/commands/experimental.rb +19 -5
data/lib/svnauto/commands/externals.rb +128 -0
data/lib/{sc → svnauto}/commands/info.rb +1 -1
data/lib/{sc → svnauto}/commands/list.rb +3 -1
data/lib/{sc → svnauto}/commands/release.rb +39 -7
data/lib/{sc → svnauto}/config_file.rb +3 -3
data/lib/{sc/path.rb → svnauto/constants.rb} +24 -18
data/lib/{sc → svnauto}/dispatcher.rb +11 -4
data/lib/svnauto/path.rb +138 -0
data/lib/{sc → svnauto}/project.rb +16 -11
data/lib/{sc → svnauto}/repository.rb +2 -2
data/lib/{sc → svnauto}/svn.rb +51 -10
data/lib/svnauto/svn_externals.rb +187 -0
data/lib/svnauto/svn_info.rb +96 -0
data/lib/{sc → svnauto}/version.rb +2 -2
data/test/setup.rb +24 -28
data/test/test_bug.rb +10 -10
data/test/test_checkout.rb +3 -3
data/test/test_create.rb +3 -3
data/test/test_experimental.rb +33 -18
data/test/test_externals.rb +55 -0
data/test/test_path.rb +148 -0
data/test/test_release.rb +11 -11
data/test/test_svninfo.rb +17 -0
data/test/test_version.rb +16 -16
metadata +35 -42
data/INSTALL +0 -48
data/LICENSE +0 -22
data/README +0 -81
data/THANKS +0 -8
data/TODO +0 -8
data/doc/manual.txt +0 -241

data/README DELETED

@@ -1,81 +0,0 @@
-= What is SC?
-SC is a wrapper around Subversion that automates and standardizes branching
-and merging.  The primary goal of the project is to simplify the more complex
-features of Subversion and therefore encouraging their use.
-== Quick Start
-This is a very terse introduction to using SC.  For more information, please
-read the INSTALL file, and it is highly recommended that you read the
-doc/manual.txt file.
-=== Install SC Dependencies
-* Subversion (svn and svnadmin) (http://subversion.tigris.org/)
-* Ruby (http://www.ruby-lang.org/en/downloads/)
-* RubyGems (http://docs.rubygems.org/)
-=== Downloading and Installing SC
-SC is distributed as a RubyGem.  You can install SC using the gem command:
- > gem install svnauto --include-dependencies
-Other download options can be found at: http://rubyforge.org/projects/svnauto/
-=== Getting SC from Its Subversion Repository
- > svn co http://pmade.com/svn/oss/sc/trunk sc-trunk
-=== Configure Your Repositories
-Start by telling SC about the repositories you use:
- > sc config --add
-You can also use this method to create a new local repository.  When prompted
-for a repository URL, give a path to a nonexistent directory.
-=== Creating a Project with SC
-SC considers top-level directories in the repository to be projects.  You can
-create a new project using the SC 'create' command.  This command is
-non-destructive, so you can use it to make sure that an existing project has
-the correct directory layout.  For more information, see doc/manual.txt.
- > sc create my-new-project
-=== Making a Release of Your Project
-When it's time to make an official public release of your software, you should
-create a release branch and tag the release:
- > sc release 1.0.0
-SC uses a strict version number scheme.  Version numbers are formated as
-MAJOR.MINOR.MACRO.  Each component of the version number can be up to six
-digits long, but they are restricted to integers.
-MAJOR.MINOR version releases are kept on their own release branch.  MACRO
-releases are tags on a release branch.  For more information, see
-doc/manual.txt.
-=== Fixing Bugs on a Release Branch
-This is an example that illustrates the use of bug fix branches.  Here we take
-the necessary steps to fix a bug on the release branch.  The SC 'bug' command
-takes a unique bug identifier, which usually comes from a bug tracking system:
- > sc bug 25
- > # edit files, fix bug, test, and commit
- > sc bug --close 25
-The bug fix is then merged with the release branch and the trunk.

data/THANKS DELETED

@@ -1,8 +0,0 @@
-= Thanks
-== Contributers
-* Michael Garriss (http://crookedhideout.com/)
-  - Testing
-  - Bug fixes
-  - Inspiration

data/TODO DELETED

@@ -1,8 +0,0 @@
-= To Do List
-== Future Versions
-* Add reporting tool to report on things such as what bug fixes
-  went into which releases
-* More advanced merging
-* Support letters in version numbers, like 1.1.1a

data/doc/manual.txt DELETED

@@ -1,241 +0,0 @@
-= SC Users Manual
-== SC Command Usage
-SC is invoked in a manner similar to the Subversion svn command.  When you use
-the sc command, you supply optional command line flags, a command, and
-possibly more command line flags.
-=== SC Invocation Example
- > sc -r test create hello
-This runs the sc command, telling it to use the test repository and to create
-a project with the name hello.  Here is a more complex example:
- > sc -r test create -f hello
-=== Getting More Help
-For a list of top-level command line flags, and commands, invoke sc with
-the --help command line flag.
-=== Commands
-All work in SC is done through a command.  For information about a specific
-command, give the --help option to the command, for example:
- > sc create --help
-== Telling SC About Your Repositories
-To save you from having to enter the full URL for the repository each time you
-use SC, you can store repository URLs in the SC configuration file, which is
-~/.sc by default.
-=== Adding a Repository
-Use the SC config command to add a repository to the SC configuration file,
-for example:
- > sc config --add
-Will tell SC to prompt you to enter information about a repository.  You will
-be asked for a name for the repository.  The name is then used instead of the
-URL when invoking SC.
-=== Auto-Discovery
-If you invoke SC from a Subversion controlled directory, SC will automatically
-use the current repository URL and project name, unless you give SC the -r and
--p flags.
-== Creating a New Project
-You can use SC to create a new project directory structure in the repository.
-To do this, use the SC create command:
- > sc create my-project-name
-== Checking Out a Project
-The SC checkout command can be used to help you do a Subversion checkout:
- > sc checkout my-project-name
-By default, the trunk is checked out.  Using command line flags, you can also
-choose to checkout a release, an experimental branch, or a bug fix branch.
-== Making a Release Branch
-You normally work with your project on its trunk.  When it comes time to make
-a release of your software, you stabilize the trunk, and then make a release
-branch.  The release branch allows you to later fix bugs for a release without
-having to release the new and unstable features that now exist in the trunk.
-=== Version Numbers
-Before we talk about release branches, we must first talk about version
-numbers and what SC understands.  SC puts strict limitations on version
-numbers in order to reliably parse and sort version numbers.
-A version number is made up of three parts, MAJOR, MINOR, and MACRO.  For
-example, the version number 10.4.8 has a MAJOR version of 10, a MINOR version
-of 4 and a MACRO version of 8.
-Each part of the version number must be an integer, and must not be greater
-than 6 digits.
-SC can properly sort version numbers.  For example, version 1.0.10 comes
-after version number 1.0.2.  So, SC actually sorts the version numbers knowing
-what they mean, instead of just doing a lexical sort.
-Because of this, when using SC, you must use this version numbering scheme.
-=== Branching the Trunk for a Release
-To make a release branch from the current point of the trunk, use the SC
-release command:
- > sc release 1.0.0
-This will create a release branch for MAJOR.MINOR version 1.0, and then tag
-the release branch with MACRO version 0.
-== Fixing a Bug for a Release
-The great thing about release branches is that you can fix a bug in an older
-release, without having to create a new release from the trunk of your
-project.  This is because the trunk may contain new features that may not be
-backwards compatible, or the trunk may currently be unstable.
-To fix a bug that exists in a specific release, you would have to manually do
-the following:
-1. Branch from the release branch creating a bug fix branch
-2. Fix the bug on the bug fix branch
-3. Test and commit your fix
-4. Merge the bug fix branch to the release branch
-5. Merge the bug fix branch to the trunk
-6. Make a new release
-Step five is very important.  It ensures that the bug fix makes its way to the
-trunk, and therefore the next release.
-SC automates this process.  It relies on the fact that you assign unique bug
-identifiers to each bug using a bug tracking system.  The example below helps
-fix a bug with the ID of 5 on the latest release branch:
- > sc bug 5
- > # fix and commit
- > sc bug --close 5
-== Working With Experimental Branches
-Sometimes you might want to make a large set of changes to the trunk that will
-greatly affect the stability of the code, or might take longer than normal to
-implement.  It's even possible that you might want to make changes to the
-project that may never be released.
-SC allows you to create experimental branches for such purposes.  Experimental
-branches can be created off the trunk, and can receive changes from the trunk
-or send changes to the trunk.
-=== Creating an Experimental Branch
-To create an experimental branch, use the SC experimental command, of course,
-that's a bit much to type, so SC allows you to abbreviate it:
- > sc exp testing-new-parser
-This creates a new experimental branch called testing-new-parser.
-=== Merging the Current Trunk to the Experimental Branch
-Use the SC experimental command with the --up flag:
- > sc exp --up testing-new-parser
-=== Merging the Experimental Branch to the Trunk
-Use the SC experimental command with the --down flag:
- > sc exp --down testing-new-parser
-== Theory
-This section aims to help the SC user understand the implementation decisions
-that were made.
-=== Inspiration
-The layout of the repository was mostly inspired by:
-  Pragmatic Version Control, Using Subversion
-  By Mike Mason
-  ISBN 0-9745140-6-3
-The process for creating release branches and tags is based on the one used by
-the FreeBSD Release Engineering Team: http://www.freebsd.org/releng/
-=== Repository Layout
-The directories at the top-level of the repository are considered to be
-projects.  In each project, a very specific directory structure is maintained.
-==== The Trunk Directory
-The trunk directory is used to store the most current version of the project.
-There is no enforcement of the structure inside the trunk.  Developers usually
-work on the trunk until a point in time where the source code in the trunk
-becomes stable.  At this time, a branch of the trunk is made.
-==== The Branches Directory
-The branches directory is used to store branches made of the project.  This
-includes release branches, bug fix branches, and experimental branches.
-==== The Tags Directory
-The tags directory is used to record a point in time for the project.  This
-includes the time at which releases where made, or bug fix branches were
-created.
-==== Branches and Tags Subdirectories
-The branches and tags directories both include the following subdirectories:
-  rel: For releases
-  bug: For bug fixes
-  exp: For experimental code
-==== Repository Structure Visualization
- myproject:
-  |
-  +--trunk
-  |   |
-  |   +--project-files
-  |
-  +--branches
-  |   |
-  |   +--rel
-  |   +--bug
-  |   +--exp
-  |
-  +--tags
-      |
-      +--rel
-      +--bug
-      +--exp