07-03-2016, 11:50 PM
The way we work here is more or less like this:
- we create a repository for all installs
- we start the repository by pulling in all commits from coreBOS, this links both projects together
- we aork on the new project and commit any specific project files (for example, it's changesets which are only for this project) to it's repository
- if we need to modify the base code two things can happen:
1.- the change is something that coreBOS should have or we can enhance coreBOS (global variable, corebos event, ....) so that this project can simply configure or add the functionality without changing base code. In this case we modify coreBOS (if needed), commi the change there and do a new pull into this project. We adapt accordingly.
2.- the change is really something specific to this project and enhancing coreBOS to support it really doesn't benefit anybody. In this case we simply make the change and commit it inside this project. That way we always have it documented and under code control. When we pull again from the base coreBOS, we will fix the conflicts manually.
So, look at it this way:
- if you need to modify base code: think about enhancing coreBOS so you won't have to change it again in the future. In fact it is an opportinity to make the applicationmore flexible.
- if you get a code conflict while doing a pull, it is an opportunity to learn something new about the application. Most probably something that you had hard coded can now be customized, take the opportunity to learn how and eliminate a dependency from your code
HTH
- we create a repository for all installs
- we start the repository by pulling in all commits from coreBOS, this links both projects together
- we aork on the new project and commit any specific project files (for example, it's changesets which are only for this project) to it's repository
- if we need to modify the base code two things can happen:
1.- the change is something that coreBOS should have or we can enhance coreBOS (global variable, corebos event, ....) so that this project can simply configure or add the functionality without changing base code. In this case we modify coreBOS (if needed), commi the change there and do a new pull into this project. We adapt accordingly.
2.- the change is really something specific to this project and enhancing coreBOS to support it really doesn't benefit anybody. In this case we simply make the change and commit it inside this project. That way we always have it documented and under code control. When we pull again from the base coreBOS, we will fix the conflicts manually.
So, look at it this way:
- if you need to modify base code: think about enhancing coreBOS so you won't have to change it again in the future. In fact it is an opportinity to make the applicationmore flexible.
- if you get a code conflict while doing a pull, it is an opportunity to learn something new about the application. Most probably something that you had hard coded can now be customized, take the opportunity to learn how and eliminate a dependency from your code
HTH
Joe
TSolucio
TSolucio