- changed status to resolved
Strategy to deal with automatic formatting, given the potential to create messy conflicts in active branches
USE CASE: WHAT DO YOU WANT TO DO?
Start using the automatic formatting in the change procedure.
STEPS TO REPRODUCE AN ISSUE (OR TRIGGER A NEW FEATURE)
- Before branching, but after pulling master & checking that no-one is working on the files you intend to edit, run the automatic formatter on the master branch
- After changes are done on files on which the formatter had been run in step 1, run it again before each commit of those files
- Instead of running the formatter as is described in the current procedure, run the formatter on master for any files that were additionally edited after merging the PR
CURRENT BEHAVIOR
In order to avoid conflicts in active branches, we have not been running the automatic formatting and instead have been waiting until all active branches are merged before doing automatic formatting. In instances where formatting was done during branch work, real changes become buried among formatting changes, causing reviewers to go to individual commits to do reviews. This is problematic for various reasons, mainly due to inflexibility of bitbucket's PR interface.
EXPECTED BEHAVIOR
Temporarily adjust the auto-formatting step(s) in the change procedure to do formatting on specific files directly in master. Level of effort is trivial, thus commits directly to master are allowed. This will make reviews much easier.
DEVELOPERS ONLY SECTION
SUGGESTED CHANGE (Pseudocode optional)
See expected behavior above.
FILES AFFECTED (where the changes will be implemented) - developers only
- SCMP_TreeView3.doc, section 3.2.1 CHANGE CONTROL OVERVIEW PROCEDURE
- SCMP_TreeView3.doc, section 3.2.6.2.2 MERGE REQUEST PROCEDURE
LEVEL OF EFFORT - developers only
minor
COMMENTS
Comments (3)
-
reporter -
reporter - changed status to closed
Merged to master
-
reporter - changed version to beta2
- Log in to comment
Changes are implemented in branch issue463-464-469.