svnauto 1.0.0

data/INSTALL

@@ -0,0 +1,48 @@
+= SC Installation
+
+Installing SC should be pretty simple, especially if you already have Ruby and
+RubyGems installed.
+
+== Install Subversion
+
+SC uses the svn and svnadmin command line clients that come with Subversion.
+It's highly likely that you already have Subversion installed, but if not, you
+can download the source code from http://subversion.tigris.org/ or follow your
+operating system's procedures for installing third-party software.
+
+
+== Install Ruby
+
+Ruby is pre-installed on many operating systems.  If for some reason you don't
+have Ruby installed, you'll need to follow your operating system's procedures
+for installing Ruby.
+
+For example, on FreeBSD you can:
+
+ > cd /usr/ports/lang/ruby18 && make install clean
+
+You can also build Ruby from source.  See the Ruby website
+(http://www.ruby-lang.org) for more information.
+
+
+== Install RubyGems
+
+RubyGems is a software package system for software written in Ruby.  You may
+already have RubyGems installed.  Try running this:
+
+ > gem -v
+
+If you don't have RubyGems installed, you can do so by following the
+instructions on: http://rubygems.org/
+
+Alternatively, you can use your operating system's package feature, if so
+equipped.  For example, on FreeBSD:
+
+ > cd /usr/ports/devel/ruby-gems && make install clean
+
+
+== Install SC
+
+SC is distributed as a RubyGem.  You can install SC using the gem command:
+
+ > gem install svnauto --include-dependencies

data/LICENSE

@@ -0,0 +1,22 @@
+== License
+
+Copyright (C) 2006 Peter J Jones (pjones@pmade.com)
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

data/README

@@ -0,0 +1,81 @@
+= 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

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

data/TODO

@@ -0,0 +1,9 @@
+= To Do List
+
+== Before Version 1.0.0
+
+* Create the intro screencast
+
+== Future Versions
+
+* Support letters in version numbers, like 1.1.1a

data/bin/sc

@@ -0,0 +1,35 @@
+#!/usr/bin/env ruby
+################################################################################
+#
+# Copyright (C) 2006 Peter J Jones (pjones@pmade.com)
+#
+# Permission is hereby granted, free of charge, to any person obtaining
+# a copy of this software and associated documentation files (the
+# "Software"), to deal in the Software without restriction, including
+# without limitation the rights to use, copy, modify, merge, publish,
+# distribute, sublicense, and/or sell copies of the Software, and to
+# permit persons to whom the Software is furnished to do so, subject to
+# the following conditions:
+# 
+# The above copyright notice and this permission notice shall be
+# included in all copies or substantial portions of the Software.
+# 
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+# NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+# LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+# OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+# WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+#
+################################################################################
+require 'rubygems'
+require 'sc'
+
+begin
+  SC::Dispatcher.new.run
+rescue RuntimeError => e
+  $stderr.puts "#{SC::Constants::TERMINAL.color(SC::Constants::ME, :red)}: #{e}"
+  exit 1
+end
+################################################################################

data/doc/manual.txt

@@ -0,0 +1,241 @@
+= 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