You can keep the software codes in a local environment. You can periodically back up your files and you may not feel that you need a source control system.
Here are the reasons why we need a source control system and what a source control can do for us:
This is particularly important when you start delivering your software to customers. You want to keep track the version that the customer has and that may be different from your latest code.
You want to know why a change was made and when there is an issue, you can go back to a specific version a a point in time in the past.
For this reason, every time when a chance is made, or at least an important change is made, the old before-change image is kept and a new copy of the file is created. The system will ask you to enter the change reasons. This type of revision control is very basic of any of the important doc, such as contracts. If the source codes are important, tracking the changes over time is important.
#1 can be accomplish by frequently and periodically creating backup. For example, taking a daily snapshot of your development code repository. Taking a backup itself is not sufficient as a source control system as there is no "control".
A very basic control is that when a change is being made, to prevent other people to make other changes to the same file, the developer should be able to lock the object and prevent other people from making changes to it. The step is typically called Check-Out.
This is required if multiple developers may update the same source files.
A more sophisticate system may allow changes but asking the developers about how to merge the changes during Check-In.
Asking developers to check-out before making the change can provide a much better auditing. Even though you may assign codes exclusively to specific developers, people may accidentally over write other people's file.
A transaction is a logical unit of changes to multiple objects that need to go hand in hand.
When a transaction is committed. All changes made inside the transaction is committed. When a transaction is rollback, all changes made as part of the transactions are rolled back.
Having a concept of a transaction as part of the source control system can ensure the dependencies among the changes are covered.
When a change is not ready to be consumed by others, if a system cannot support transaction based check-in, you need to hold the change in a local system to not check the change in with the risk of losing it. After all the dependent objects are made together, all changes are checked in together.
If you have a transaction based check-in from the source control system, you can check in (or simply save) the individual changes to the transaction, and submit the changes together.
Here are the reasons why we need a source control system and what a source control can do for us:
1. Keep tracking the changes over time
This is particularly important when you start delivering your software to customers. You want to keep track the version that the customer has and that may be different from your latest code.
You want to know why a change was made and when there is an issue, you can go back to a specific version a a point in time in the past.
For this reason, every time when a chance is made, or at least an important change is made, the old before-change image is kept and a new copy of the file is created. The system will ask you to enter the change reasons. This type of revision control is very basic of any of the important doc, such as contracts. If the source codes are important, tracking the changes over time is important.
2. Concurrency control
#1 can be accomplish by frequently and periodically creating backup. For example, taking a daily snapshot of your development code repository. Taking a backup itself is not sufficient as a source control system as there is no "control".
A very basic control is that when a change is being made, to prevent other people to make other changes to the same file, the developer should be able to lock the object and prevent other people from making changes to it. The step is typically called Check-Out.
This is required if multiple developers may update the same source files.
A more sophisticate system may allow changes but asking the developers about how to merge the changes during Check-In.
Asking developers to check-out before making the change can provide a much better auditing. Even though you may assign codes exclusively to specific developers, people may accidentally over write other people's file.
3. Transaction based check in
A transaction is a logical unit of changes to multiple objects that need to go hand in hand.
When a transaction is committed. All changes made inside the transaction is committed. When a transaction is rollback, all changes made as part of the transactions are rolled back.
Having a concept of a transaction as part of the source control system can ensure the dependencies among the changes are covered.
When a change is not ready to be consumed by others, if a system cannot support transaction based check-in, you need to hold the change in a local system to not check the change in with the risk of losing it. After all the dependent objects are made together, all changes are checked in together.
If you have a transaction based check-in from the source control system, you can check in (or simply save) the individual changes to the transaction, and submit the changes together.
No comments:
Post a Comment