deon/phptsmadmin
Archived
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update Kohana to 3.1.3.1

Browse Source
This commit is contained in:
Deon George
2011-05-16 22:47:16 +10:00
parent 8b658b497a
commit ff2370c368
401 changed files with 14070 additions and 10213 deletions
Download Patch File Download Diff File Expand all files Collapse all files

150
includes/kohana/modules/userguide/guide/developers.md Normal file
View File

@@ -0,0 +1,150 @@
# 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.

2
includes/kohana/modules/userguide/guide/userguide/adding.md
View File

@@ -22,7 +22,7 @@ First, copy this config and place in it `<module>/config/userguide.php`, replaci
'description' => '<Description goes here.>',
// Copyright message, shown in the footer for this module
'copyright' => '&copy; 2010–2010 <Your Name>',
'copyright' => '&copy; 2010–2011 <Your Name>',
)
)
);

33
includes/kohana/modules/userguide/guide/userguide/contributing.md
View File

@@ -20,7 +20,7 @@ If you want to contribute some changes, you can do so right from your browser wi
First create an account on [Github](https://github.com/signup/free).
You will need to fork the module for the area you want to improve. For example, to improve the [ORM documentation](../orm) fork <http://github.com/bluehawk/orm>. To improve the [Kohana documentation](../kohana), fork <http://github.com/bluehawk/core>, etc. So, find the module you want to improve and click on the Fork button in the top right.
You will need to fork the module for the area you want to improve. For example, to improve the [ORM documentation](../orm) fork <http://github.com/kohana/orm>. To improve the [Kohana documentation](../kohana), fork <http://github.com/kohana/core>, etc. So, find the module you want to improve and click on the Fork button in the top right.
![Fork the module](contrib-github-fork.png)
@@ -38,34 +38,21 @@ Once your pull request has been accepted, you can delete your repository if you
## If you know git
**Bluehawk's forks all have a `docs` branch. Please do all work in that branch.**
To make pulling all the docs branches easier, the "docs" branch of [http://github.com/bluehawk/kohana](http://github.com/bluehawk/kohana) contains git submodule links to all the other "docs" branches, so you can clone that to easily get all the docs. The main Kohana docs are in [http://github.com/bluehawk/core/tree/docs/guide/kohana/], and docs for each module are in the respective module in the guide folder. (Again, make sure you are in the `docs` branch.)
**Short version**: Fork bluehawk's fork of the module whose docs you wish to improve (e.g. `git://github.com/bluehawk/orm.git` or `git://github.com/bluehawk/core.git`), checkout the `docs` branch, make changes, and then send bluehawk a pull request.
**Short version**: Create a ticket on redmine for your changes, fork the module whose docs you wish to improve (e.g. `git://github.com/kohana/orm.git` or `git://github.com/kohana/core.git`), checkout the appropriate branch, make changes, and then send a pull request with the ticket number.
**Long version:** (This still assumes you at least know your way around git, especially how submodules work.)
1. Fork the specific repo you want to contribute to on github. (For example go to http://github.com/bluehawk/core and click the fork button.)
1. Create a ticket on redmine for your changes.
1. To make pulling the new userguide changes easier, I have created a branch of `kohana` called `docs` which contains git submodules of all the other doc branchs. You can either manually add my remotes to your existing kohana repo, or create a new kohana install from mine by doing these commands:
git clone git://github.com/bluehawk/kohana
# Get the docs branch
git checkout origin/docs
# Fetch the system folder and all the modules
git submodule init
git submodule update
2. Fork the specific repo you want to contribute to on github. (For example go to http://github.com/kohana/core and click the fork button.)
1. Now go into the repo of the area of docs you want to contribute to and add your forked repo as a new remote, and push to it.
3. Now go into the repo of the area of docs you want to contribute to and add your forked repo as a new remote, and push to it.
cd system
# make sure we are up to date with the docs branch
git merge origin/docs
(if this fails or you can't commit later type "git checkout -b docs" to create a local docs branch)
# make sure we are up to date
git checkout 3.1/develop
git pull
# add your repository as a new remote
git remote add <your name> git@github.com:<your name>/core.git
@@ -74,6 +61,6 @@ To make pulling all the docs branches easier, the "docs" branch of [http://githu
# now commit the changes and push to your repo
git commit
git push <your name> docs
git push <your name> 3.1/develop
1. Send a pull request on github.
4. Send a pull request on github containing the ticket number, and update the ticket with a link to the pull request.