Contribute to projects - Revision history

Brad Berg: /* Check In Changed Code */

2010-04-23T14:15:02Z

Check In Changed Code

← Older revision		Revision as of 14:15, 23 April 2010
Line 28:		Line 28:
	The commit comment is logged in the history for the file. It is a terse reminder for the change. When checking in a group of files use the same message for all the files.		The commit comment is logged in the history for the file. It is a terse reminder for the change. When checking in a group of files use the same message for all the files.

	After you are done submitting changes verify that they are correct. Create and go into a scratch directory for testing ~~(See [[Software tests\|Create and automate software tests]])~~. Check out the project, build it, and run it to see that it still works.		After you are done submitting changes verify that they are correct. Create and go into a scratch directory for testing. Check out the project, build it, and run it to see that it still works (See [[Software tests\|Create and automate software tests]]).

Brad Berg: /* Check In Changed Code */

2010-04-23T14:14:13Z

Check In Changed Code

← Older revision		Revision as of 14:14, 23 April 2010
Line 28:		Line 28:
	The commit comment is logged in the history for the file. It is a terse reminder for the change. When checking in a group of files use the same message for all the files.		The commit comment is logged in the history for the file. It is a terse reminder for the change. When checking in a group of files use the same message for all the files.

	After you are done submitting changes verify that they are correct. Create and go into a scratch directory for testing. Check out the project, build it, and run it to see that it still works.		After you are done submitting changes verify that they are correct. Create and go into a scratch directory for testing (See [[Software tests\|Create and automate software tests]]). Check out the project, build it, and run it to see that it still works.

Brad Berg: /* Check In Changed Code */

2010-04-23T13:04:17Z

Check In Changed Code

← Older revision		Revision as of 13:04, 23 April 2010
Line 27:		Line 27:

	The commit comment is logged in the history for the file. It is a terse reminder for the change. When checking in a group of files use the same message for all the files.		The commit comment is logged in the history for the file. It is a terse reminder for the change. When checking in a group of files use the same message for all the files.

			After you are done submitting changes verify that they are correct. Create and go into a scratch directory for testing. Check out the project, build it, and run it to see that it still works.

Brad Berg at 13:01, 23 April 2010

2010-04-23T13:01:38Z

@@ Line 1: / Line 1: @@
 When working on existing projects be sure to coordinate with peers working with the same code.  In particular make sure that changes you make do not adversely impact others.
 The CVS repository contains the most recent software version.  It is continuously changing and which means that it is inherently unstable and may introduce recent errors.  Before you update your sandbox from CVS you should save any working copies you have.  This way if the update fails then you can revert to your previous copy.
@@ Line 8: / Line 10: @@
 If the project does not have any tests then it is a good idea to add some.  This way after you can see that your changes did not have damaging side effects.  A simple smoke test is a reasonable start and will catch obvious errors.

Brad Berg at 14:46, 22 April 2010

2010-04-22T14:46:25Z

← Older revision		Revision as of 14:46, 22 April 2010
Line 1:		Line 1:
	When working on existing projects be sure to coordinate with peers working with the same ~~project~~. In particular make sure that changes you make do not adversely impact others.		When working on existing projects be sure to coordinate with peers working with the same code. In particular make sure that changes you make do not adversely impact others.

	The CVS repository contains the most recent software version. It is continuously changing and which means that it is inherently unstable and may introduce recent errors. Before you update your sandbox from CVS you should save any working copies you have. This way if the update fails then you can revert to your previous copy.		The CVS repository contains the most recent software version. It is continuously changing and which means that it is inherently unstable and may introduce recent errors. Before you update your sandbox from CVS you should save any working copies you have. This way if the update fails then you can revert to your previous copy.

	Software development ~~involves many~~ complex interdependencies ~~so we~~ will all make mistakes~~. Your~~ work flow should take this into consideration. However, it is beneficial to keep the repository in good working condition. If you do make a mistake please try to ~~repair~~ it quickly. Also after you check in changes, check them out into a test directory so you can check your results.		Software development is an ad hoc process with complex interdependencies that are often indirect or hidden. We will all make mistakes and your work flow should take this into consideration. However, it is beneficial to keep the repository in good working condition. If you do make a mistake please try to correct it quickly. Also after you check in changes, check them out into a test directory so you can check your results.

	As you browse existing code this is a good opportunity to make minor changes to make the code more readable. Reformat code that is cluttered or is not evenly lined up. As you learn how the code operates add comments so the next person does not need to reverse engineer it again.		As you browse existing code this is a good opportunity to make minor changes to make the code more readable. Reformat code that is cluttered or is not evenly lined up. As you learn how the code operates add comments so the next person does not need to reverse engineer it again.

	If the project does not have any tests then it is a good idea to add some. This way after you can see that your changes did not have damaging side effects. A simple smoke test is a reasonable start and will catch obvious errors.		If the project does not have any tests then it is a good idea to add some. This way after you can see that your changes did not have damaging side effects. A simple smoke test is a reasonable start and will catch obvious errors.

Brad Berg at 14:29, 22 April 2010

2010-04-22T14:29:30Z

← Older revision		Revision as of 14:29, 22 April 2010
Line 1:		Line 1:
	When working on existing projects be sure to coordinate with peers working with the same project. In particular make sure that changes you make do not adversely impact others.		When working on existing projects be sure to coordinate with peers working with the same project. In particular make sure that changes you make do not adversely impact others.

			The CVS repository contains the most recent software version. It is continuously changing and which means that it is inherently unstable and may introduce recent errors. Before you update your sandbox from CVS you should save any working copies you have. This way if the update fails then you can revert to your previous copy.

			Software development involves many complex interdependencies so we will all make mistakes. Your work flow should take this into consideration. However, it is beneficial to keep the repository in good working condition. If you do make a mistake please try to repair it quickly. Also after you check in changes, check them out into a test directory so you can check your results.

	As you browse existing code this is a good opportunity to make minor changes to make the code more readable. Reformat code that is cluttered or is not evenly lined up. As you learn how the code operates add comments so the next person does not need to reverse engineer it again.		As you browse existing code this is a good opportunity to make minor changes to make the code more readable. Reformat code that is cluttered or is not evenly lined up. As you learn how the code operates add comments so the next person does not need to reverse engineer it again.

	If the project does not have any tests then it is a good idea to add some. This way after you can see that your changes did not have damaging side effects. A simple smoke test is a reasonable start and will catch obvious errors.		If the project does not have any tests then it is a good idea to add some. This way after you can see that your changes did not have damaging side effects. A simple smoke test is a reasonable start and will catch obvious errors.

Brad Berg: New page: When working on existing projects be sure to coordinate with peers working with the same project. In particular make sure that changes you make do not adversely impact others. As you bro...

2010-04-22T14:03:25Z

New page: When working on existing projects be sure to coordinate with peers working with the same project. In particular make sure that changes you make do not adversely impact others. As you bro...

New page

When working on existing projects be sure to coordinate with peers working with the same project. In particular make sure that changes you make do not adversely impact others.

As you browse existing code this is a good opportunity to make minor changes to make the code more readable. Reformat code that is cluttered or is not evenly lined up. As you learn how the code operates add comments so the next person does not need to reverse engineer it again.

If the project does not have any tests then it is a good idea to add some. This way after you can see that your changes did not have damaging side effects. A simple smoke test is a reasonable start and will catch obvious errors.