diff --git a/DEVELOPERS.md b/DEVELOPERS.md deleted file mode 100644 index 80709ef..0000000 --- a/DEVELOPERS.md +++ /dev/null @@ -1,150 +0,0 @@ -# Distributed Source Control Management - -Unlike SVN, git does not used a central repository. This is why git is "distributed" and SVN is -"centralized". Although this makes git an extremely powerful system for collaborators, tracking -changes between various collaborators can quickly become difficult as multiple forks are created. - -Please read the following before working with this code: - -1. [Dealing with newlines](http://github.com/guides/dealing-with-newlines-in-git) -2. [Submitting changes from your fork](http://github.com/guides/fork-a-project-and-submit-your-modifications) -3. [Using SSH keys with github](http://github.com/guides/how-to-not-have-to-type-your-password-for-every-push) - -## Managing Remote Repositories - -First, you will need to tell git about the remote repository: - - > git remote add kohana git://github.com/kohana/kohana.git - -This tells git about the kohana repository and gives it a name which we can use to refer to it when -fetching changes from the repository. - -## Developing locally - -There are 3 branches in all the kohana repositories: - -* **master** This branch always points to the latest release tag. In essence it points to the last stable edition of the codebase -* **3.0.x** This is a release branch for development of the 3.0.x series, i.e. 3.0, 3.0.3, 3.0.8 etc. -* **3.1.x** This is a release branch for development of the 3.1.x series, i.e. 3.1, 3.1.4, 3.1.14 etc. - -To work on a specific release branch you need to check it out then check out the appropriate branches. -Release branch names follow the same convention in both kohana/kohana and kohana/core. - -To work on 3.0.x you'd do the following: - - > git clone git://github.com/kohana/kohana.git - .... - - > cd kohana - > git submodule update --init - .... - - > git checkout 3.0.x - Switched to branch '3.0.x' - > git submodule update - - > cd system - > git checkout 3.0.x - # Switched to branch 3.0.x - -It's important that you follow the last step, because unlike svn, git submodules point at a -specific commit rather than the tip of a branch. If you cd into the system folder after -a `git submodule update` and run `git status` you'll be told: - - # Not currently on any branch. - nothing to commit (working directory clean) - -Similarly, if you want to work on modules, make sure you checkout the correct branch before you start working. - -**IMPORTANT:** It is highly recommended that you run the unit tests whilst developing to -ensure that any changes you make do not break the api. *See TESTING.md for more info* - -### Creating new features - -New features or API breaking modifications should be developed in separate branches so as to isolate them -until they're stable and **tests have been written for the feature**. - -The naming convention for feature branches is: - - feature/{issue number}-{short hyphenated description} - - // i.e. - - feature/4045-rewriting-config-system - -When a new feature is complete and tested it can be merged into its respective release branch using -`git pull --no-ff`. The `--no-ff` switch is important as it tells git to always create a commit -detailing what branch you're merging from. This makes it a lot easier to analyse a feature's history. - -Here's a quick example: - - > git status - # On branch feature/4045-rewriting-everything - - > git checkout 3.1.x - # Switched to branch '3.1.x' - - > git merge --no-ff feature/4045-rewriting-everything - -**If a change you make intentionally breaks the api then please correct the relevant tests before pushing!** - -### Bug fixing - -If you're making a bugfix then before you start create a unit test which reproduces the bug, -using the `@ticket` notation in the test to reference the bug's issue number -(i.e. `@ticket 4045` for issue #4045). - -If you run the test then the one you've just made should fail. - -Once you've written the bugfix, run the tests again before you commit to make sure that the -fix actually works,then commiti both the fix and the test. - -There is no need to create separate branches for bugfixes, creating them in the main release -branch is perfectly acceptable. - -## Merging Changes from Remote Repositories - -Now that you have a remote repository, you can pull changes in the remote "kohana" repository -into your local repository: - - > git pull kohana master - -**Note:** Before you pull changes you should make sure that any modifications you've made locally -have been committed. - -Sometimes a commit you've made locally will conflict with one made in the "kohana" one. - -There are a couple of scenarios where this might happen: - -### The conflict is to do with a few unrelated commits and you want to keep changes made in both commits - -You'll need to manually modify the files to resolve the conflict, see the "Resolving a merge" -section [in the git-scm book](http://book.git-scm.com/3_basic_branching_and_merging.html) for more info - -### You've fixed something locally which someone else has already done in the remote repo - -The simplest way to fix this is to remove all the changes that you've made locally. - -You can do this using - - > git reset --hard kohana - -### You've fixed something locally which someone else has already fixed but you also have separate commits you'd like to keep - -If this is the case then you'll want to use a tool called rebase. First of all we need to -get rid of the conflicts created due to the merge: - - > git reset --hard HEAD - -Then find the hash of the offending local commit and run: - - > git rebase -i {offending commit hash} - -i.e. - - > git rebase -i 57d0b28 - -A text editor will open with a list of commits, delete the line containing the offending commit -before saving the file & closing your editor. - -Git will remove the commit and you can then pull/merge the remote changes. diff --git a/TESTING.md b/TESTING.md deleted file mode 100644 index ffb17e6..0000000 --- a/TESTING.md +++ /dev/null @@ -1,36 +0,0 @@ -Unit Testing Kohana -=== - -Guidelines for writing unit tests ---- - - * Use @covers - This helps provide proper code coverage - * Use providers when appropriate - This helps keep your tests simple and makes it easy to add new test cases. - * When a new feature of bug fix is applied, create a test for it. This may only consist of adding a provider. - -How to use the tests ---- - -Simply run `phpunit` from this directory. PHPUnit will grab the config settings stored in phpunit.xml and run -the tests for kohana. If everything goes ok phpunit should print a series of dots (each dot represents a test that's passed) -followed by something along the lines of `OK (520 tests, 1939 assertions)`. - -If the result is instead something like `Ok but skipped or incomplete tests` then this just means that some tests were unable to run -on your system or their implementation is not quite finished. - -By default code coverage is not calculated, if you want to collect it then you need to run `./phpunitcc` which will -run phpunit with the config in `code_coverage.xml`. Once the tests have finished running open `code_coverage/index.html` -in your browser. - -Things to Test (TODO) ---- - -* Need extra tests for Validate to make sure filters(), rules(), callbacks() will convert the field name to a label if a label - does not exist - -Known failing tests ---- - -NONE - - * If any other tests fail for your system, please [file a bug](http://dev.kohanaframework.org/projects/kohana3/issues/new) diff --git a/build.xml b/build.xml index 4a7fe65..cb32fad 100644 --- a/build.xml +++ b/build.xml @@ -172,12 +172,12 @@ - + - + diff --git a/code_coverage.xml b/code_coverage.xml deleted file mode 100644 index cd9a0e5..0000000 --- a/code_coverage.xml +++ /dev/null @@ -1,18 +0,0 @@ - - - - - ./system/classes/kohana/ - - - - - - - - ./system/tests/kohana/ - - - diff --git a/modules/userguide b/modules/userguide index bc1e66c..19368ae 160000 --- a/modules/userguide +++ b/modules/userguide @@ -1 +1 @@ -Subproject commit bc1e66c149938132492fea5548fb512d36581ddd +Subproject commit 19368aedc825280cc4850d3e63c05d55b989b264 diff --git a/phpunit.xml b/phpunit.xml deleted file mode 100644 index 254ebd2..0000000 --- a/phpunit.xml +++ /dev/null @@ -1,13 +0,0 @@ - - - - - ./system/classes/kohana/ - - - - - ./system/tests/kohana/ - - - diff --git a/phpunitcc b/phpunitcc deleted file mode 100755 index 8a32501..0000000 --- a/phpunitcc +++ /dev/null @@ -1,3 +0,0 @@ -#!/bin/bash - -echo -e "`phpunit --configuration code_coverage.xml $@`"