Welcome to the CMU-SV rails project for the Education group.
Check out the design document inside docs
For individual maintainers, please fork the project on github, make your changes, and submit a pull request.
For teams doing project work for a course, please follow the directions provided in the course. We’ll probably give you a repository to work from. Each new feature should be done in its own branch.
I’ve enjoyed talking with various teams about your MfSE experience: the fun of hiding bugs and the frustration of the chase in trying to find bugs added by others. It almost reminds me of Easter Egg hunts. I get VERY excited about students finding bugs already present in the code. If you did find one, congratulations! I’m now inviting you to join the project and submit a bug fix.
Not sure if you found an original bug, I’m here to help! Call me or email me.
The process is pretty simple. If you have never used github, then follow the direction in the next section
This is the same process you would use in working with any open source project. If you want detailed directions with screen snapshots, see help.github.com/forking/ – Go to github and login with your account. Then click on “fork” this project. This will create your own personal repository that you can play with. On your own desktop, you will want to do a git clone of your repository url. Your url will look something like this: git@github.com:USERNAME/cmusv.git – add in a test case that exposes the bug, fix the bug, see that the test case passes. Great, you are almost done. Do a “git add .” “git commit” and a “git push” to get your change onto your personal repository on github. You then will want to get your change into my repository. Do a “git pull request” – that will send your new code to me and we can have a dialog about the change.
Follow these directions: info.sv.cmu.edu/do/view/CurriculumLogistics/RubyOnRailsInstallation#Install_GIT_client_source_contro
Read: git.wiki.kernel.org/index.php/LinusTalk200705Transcript
Here’s my personal list
a) You have the complete repository on your system. If you are on a train/plane, you have access to the entire history without going over the internet. b) The hash compression technique makes operations very, very fast. c) git simplifies the checkin process into different steps. You do commits against your own repository, then you do a push of all your changes to a team repository. Because Git separates the checkin into two steps, I find that I do a lot of micro commits for each push. My commit message are more meaningful. On other systems, I would only do a "commit" when I was ready to deploy my code. Now I can do commits as I finish test cases and then do a push when I have code to integrate with others.
Slides are here: curriculum.sv.cmu.edu/foundations_agile/classes/attachments/GitIntro.pdf
This is an excellent firehose experience of learning about how Git works under the covers. Unfortunately the mac mini crashed and we lost about 15 minutes of audio near the end. admin.na6.acrobat.com/admin/meeting/sco/recordings/local/info?filter-rows=20&filter-start=0&page=true()&sco-id=1051911757&select-all=true&tab-id=832037793
The criteria for code being accepted is as follows:
1. there must be test cases for all code written, we already have enough code that was test by hand (please use rspec for new test cases) 2. the code should solve a need experienced by many of our users 3. the code must be relatively well written 4. if you are considering using new gems, run your ideas by the maintainers first
This code is released under the TBD license – Copyright 2010 Todd Sedano – see “New Features” for a complete list of contributors