Guidelines For Using Code Repositories

Today I’m a little technical. I will talk about code repositories and their usages. This is an essential checklist for playing with code repositories. Everyone needs to follow this.
What is a source code repository?
A source code repository is a place where large amounts of source code are kept, either publicly or privately. They are often used by multi-developer projects to handle various versions and developers submitting various patches of code in an organized fashion. (definition from Wikipedia)
What is Checkout?
The checkout means you get/download code from the repository to start your work. A copy of files downloads to your system for further changes.
What is commit/checked-in?
commit/checked-in mean you are sending your contents/changes to the code repository. Your work will be available to others when they will checkout/update from the same code repository.
What is a code update?
Update means you synchronize your downloaded/checked out code with the repository. Anyone else who has checked in/commit some changes in the repository, those changes will be merged/added to your copy of the codebase. Your changes will not be sent to the codebase until you commit/checked-in them.
General guidelines working with code repositories
Before starting your work
- Always update your code before the start of your work. Tts more important when you are working in a team, so if anyone else has committed some code after your last update, you may have the latest/updated version of code to start your work.
- It will also prevent having so many conflicts while updating/committing at day end with the bulk of code need to synchronize between you and the code repository.
- Confirm that your changes are working fine on your machine.
- Update your code again, so that you may have the latest code. (update once before starting your work and once when you are going to commit)
- If there are some conflicted files, resolve them very carefully. At any point, if you are confused, don’t make any assumptions and instantly ask someone to help out. It’s a very sensitive step and needs much attention and care.
- Once you have updated code and conflicts has been resolved, build and run the application again. Confirm your changes and those areas where you resolved conflicts, and/or have merged/updated files.
- If you feel something isn’t going good (compile-time error or application’s behaviour isn’t proper in some scenario) ask your lead to verify, or discuss with your team member to resolve them. It normally happens when you are working in a team and some program logic conflicts between two developers when the code repository merge the codes. (it is one possible cause, some other reasons might be there)
- Check the status of files you have. If there are some un-versioned files (those files which you added in your project manually like images, new classes etc) First add them to the repository using add option.
- Once new files have been added to the repository, commit your code using the commit option. Make a habit of providing proper comments while committing. It will not only help you but others too to know what changes were made in a specific version. Sometimes we need to get the old status of code (from some older revision) so in such a situation comments helps a lot to track the changes and status of the codebase.
- After committing, check the status of your code again using the status command. There shouldn’t be any edited/modified and newly added files that need to commit. Your codebase should be clean and fully updated.
- Before the start of any change, update your code.
- As soon as you fix a bug or made such a change that your code is in working stable form, commit that change. Don’t Keep your change till day end. Be Updated and let others too.
Moreover, it is common that different developers to use the same svn user to update/commit their code. So in such a situation, mention your name in svn comments at the time of code commit so that it becomes more clear to know who committed what and when.
Anyone who feels hesitation or fear while updating/committing code, keep a copy of this checklist and make sure not to miss any point. Ask your peer or lead instantly in case you are confused about what to do next. I’m here too to clear any query regarding the repositories usage.
Happy Development.
main bhi parhon..
You can, if and only if you can digest some techno terms. It will be dry for a person who designs and crafts creative things. ((: