Guidelines for using code repositories;

Posted on Updated on

Hello everyone;

Hope you are doing good at your desks;While-cloud-computing-has-many-uses-in-business--it-is-not-a-security-cure-all-_16001084_800874468_0_0_14061754_300

Today im lil technical; Will talk about code repositories and their usages; This is an essential checklist for playing with code repositories; Everyone need to follow this;

If I miss anything, or any point where you feel something need to describe more clearly, kindly correct me;
So lets starts;

What is 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?
In svn or cvs, checkout means you get/download code from repository to start your work; A copy of files download to your system for further changes;

What is commit/checked-in?
commit/checked-in mean you are sending your contents/changes to code repository; Your work will be available to others when they will checkout/update from same code repository;

What is update?
Update mean you synchronize your downloaded/checkedout code with repository; Anyone else who has checked-in/commit some changes in repository, those changes will be merged/added to your copy of code base; Your changes will not be sent to code base until you commit/checked-in them;

So here we go; These guidelines will help you to use code repositories in best way while working individually or in a team;
Before start of work;
  • Always update your code before 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 latest/updated version of code to start your work;
  • It will also prevent having so much conflicts while update/commit at day end with bulk of code need to synchronize between you and code repository;
When you have made your changes and ready to commit your code;
  • Confirm that your changes are working fine at your machine;
  • Update your code again, so that you may have 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 confuse, don’t made any assumption and instantly ask someone to help out; Its a very sensitive step and need 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 somethings isn’t going good (compile time error or application’s behavior isn’t proper in some scenario) ask your lead to verify, or discuss with your team member to resolve them; Its normally happen when you are working in team and some program logic conflicts between two developers when code repository merge the codes; (it is one possible case, some other reasons might be there)
When everything is good; its time to commit your code;
  • Check the status of files you have; If there is some un-versioned files (those files which you added in your project manually like images, new classes etc) First add them in repository using add option;
  • Once new files has been added to repository, commit your code using commit option; Make a habit of providing proper comments while commit; It will not only help you but others too to know what changes were made in a specific version; Sometimes we need to get old status of code (from some older revision) so in such situation comments helps alot to track the changes and status of code base;
  • After commit check the the status of your code again using status command; There shouldn’t be any edited/modified and newly added files need to commit; You code base should be clean and fully updated;
Important Note;
It is found that sometimes developers commit their code at day end; Its not a recommended practice at all; (atleast in my opinion). Always commit your code when you feel your code is in stable form after your changes; Keeping your changes till day end will maximize  the chances of conflicts at time of update/commit. It will take your lot of time to resolve them properly.
Remember
  • Before start of any change, update your code;
  • As soon as you fix a bug or made such change that your code is in working stable form, commit that change; Don’t Keep your change till day end. Be Updated and let other too;

Moreover,  it is common that different developer use same svn user to update/commit their code; So in such situation, mention your name in svn comments at time of code commit so that it become more clear to know who committed what and when;

Anyone who feels hesitation or fear while update/commit code, keep copy of this checklist and make sure not to miss any point; Ask your peer or lead instantly incase you are confuse what to do next; I’m here too to clear any query regarding the repositories usage;

Happy Development;

free counters

Advertisements

2 thoughts on “Guidelines for using code repositories;

    zainab said:
    January 14, 2011 at 09:39

    main bhi parhon..

      Ans responded:
      August 20, 2015 at 02:53

      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. ((:

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s