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

svnauto 1.0.2 → 1.1.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

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