1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
|
== Guide to Hacking Gitorious
=== Dependencies
Ruby libraries/bindings/gems
* BlueCloth (http://rubyforge.org/projects/bluecloth/)
* mime-types (http://rubyforge.org/projects/mime-types)
* oniguruma (http://rubyforge.org/projects/oniguruma)
* textpow (http://rubyforge.org/projects/textpow)
* chronic (http://rubyforge.org/projects/chronic)
* rmagick (http://rubyforge.org/projects/rmagick)
Libraries/applications:
* Git (http://git-scm.org)
* Oniguruma C library (http://www.geocities.jp/kosako3/oniguruma/)
* Sphinx (http://sphinxsearch.com/)
(App is deployed on mysql, although source should be free of mysql-isms/quirks)
=== The Hackers digest guide:
1. Do the normal rails app stuff (database.yml etc.)
2. Rename the config/gitorious.sample.yml file to gitorious.yml, and update it with your changes.
3a. If you want real project data, find a project, set the 'ready' status to true, create a bare git repository (git --bare init) in the directory GitoriousConfig['repository_base_path']/#{project.slug}/#{repository.name}.git, and push something to that repository (cd to a git repository with commits and do "git push path/to/the/bare/repository/you/just/created master").
3b. OR run the script/task_performer and let it create the repository for you (remember to do step 2 first)
4. Get your git on!
Consult the mailinglist (http://groups.google.com/group/gitorious) or drop in
by #gitorious on irc.freenode.net if you have questions.
=== Tasks and other scripts
* rake db:setup creates the initial database tables
* script/task_performer runs any tasks in the queue (creating repositories etc)
* script/graph_generator generates graph.
* rake ultrasphinx:configure configures sphinx
* rake ultrasphinx:index runs the search indexer
* rake ultrasphinx:daemon:start and ultrasphinx:daemon:stop manage the sphinx daemon
=== PostgreSQL
* Install the functions in vendor/plugins/ultrasphinx/lib/ultrasphinx/postgresql/
* After running "rake ultrasphinx:configure" you'll have to replace all instances of user with "user" in ultrasphinx's config file (user is a keyword in PostgreSQL).
perl -p -i -e 's/ user([^s]{1})/ "user"$1/g' config/ultrasphinx/*.conf
=== Coding style
* Two spaces, no tabs, for indention
* Don't use and and or for boolean tests, instead always use && and ||
* MyClass.my_method(my_arg) -- not my_method( my_arg ) or my_method my_arg
* Unless precedence is an issue; do .. end for multi-line blocks, braces for single line blocks
* Follow the conventions you see used in the source already
(copied mostly verbatim from dev.rubyonrails.org)
=== Branching model
Gitorious uses
[the git-flow branching model](http://nvie.com/posts/a-successful-git-branching-model/)
for branching. This means that the master branch is stable, and is
only merged to once a feature has been completed.
New features are created in feature branches (named `feature/$name`)
and then merged into the `next` branch once finished. Such features
arrive in `master` as new releases.
When contributing new features into Gitorious as merge requests, these
should be started the `next` branch, and marked as such when proposed.
The exception to this is hotfixes, which may be started from and
proposed merged into `master`. Please note that hotfixes should not
implement new functionality.
|
