Bug 1021406 - Each time pom.xml is saved, 5-6 unnecessary commits are made
Each time pom.xml is saved, 5-6 unnecessary commits are made
Product: JBoss BRMS Platform 6
Classification: JBoss
Component: Business Central (Show other bugs)
Unspecified Unspecified
high Severity medium
: ER1
: 6.0.1
Assigned To: Alexandre Porcelli
Lukáš Petrovický
Depends On:
  Show dependency treegraph
Reported: 2013-10-21 05:06 EDT by Zuzana Krejčová
Modified: 2014-08-06 15:59 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Unnecessary commits are made in the underlying GIT repo each time pom.xml is saved, that is, when the user clicks File->Save in the Project Explorer screen. This causes several messages in the GIT log to appear which are not required but also causes system degradation. Cause: Consequence: Fix: Result:
Story Points: ---
Clone Of:
Last Closed: 2014-08-06 15:59:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Zuzana Krejčová 2013-10-21 05:06:25 EDT
Description of problem:
Every time you click File -> Save on the project screen, no matter if you made any changes or not, 6 commits are made in the underlying git repository. The result is a mess in the git log.

First two commits are for .pom.xml - one deleting it, other recreating it. Next two do the same for .kmodule.xml and the last couple deletes and recreates .project.imports.

The most basic improvement is to only have one commit per file, but it still wouldn't help much.

The newly created .pom.xml is committed along with the changes done to the pom.xml, so if we have to commit the other two dot files, it would make sense to do it in that commit too, since the "changes" in those two were brought by the change in pom.xml.

I'd consider this fixed well if these commits and changes to dot files were only done if there actually was some kind of change being saved. 
(1) If I actually made some change to the project and (2) if the file now being recreated should end up with a different content. 
E.g. right now, if I add a dependency to the project, only pom.xml and .pom.xml are changed, so there is no need to recreate the .kmodule.xml and .project.imports - the new files are exactly the same as the old ones.

Version-Release number of selected component (if applicable):
BPMS 6.0 ER4
Comment 1 Edson Tirelli 2013-10-23 09:41:50 EDT
Since there are still reports of degradation over time due to the number of commits, this change is important to also help with that.
Comment 2 Toni Rikkola 2013-12-04 04:41:50 EST
All the files with changes are now committed with a single commit when save is pressed.
Comment 3 Zuzana Krejčová 2013-12-20 11:42:03 EST
I cannot, with clear conscience, mark this as verified.

Yes, there is only one commit per save. Problems?
1. Each save. Even if no change was made.
2. The commit may include files not relevant to the change. Let me explain...

First I tried to save a project state without making any change. Just for the fun of it. I saw .pom.xml being changed in git. Ok, not the best way, but... So the next thing I did - I actually made a change, I changed the project version. And saved. When I looked into git log, I see a commit with only the change in pom.xml (Yay! Right? No.). So I try the other 2 sections. 
Changing kmodule.xml produces commit with this change and a changed .pom.xml. Why .pom.xml? Because in the previous commit I changed pom.xml.
Changing project.imports produces commit with this change and a changed .kmodule.xml. Same reason as above.

So we now have a different kind of mess in the git log.

Comment 4 manstis 2014-02-04 11:08:16 EST
Alexandre, sorry, but could you take a look? Normally, if we try to save an unmodified file we don't get a commit. IDK with the "batch" operation whether this behaviour remains unchanged? The comment above implies all files in a batch are committed even if unchanged.
Comment 5 Alexandre Porcelli 2014-02-05 10:09:16 EST
Unnecessary dot files were already fixed by these commits (from #1049368):

(6.0.x) http://github.com/droolsjbpm/guvnor/commit/7a42d37a3
(master) http://github.com/droolsjbpm/guvnor/commit/bcf1c1396

Couldn't reproduce empty commits nor multiple commits (tested with master and 6.0.x branches).
Comment 6 Zuzana Krejčová 2014-02-06 04:07:36 EST
With CR2, behaviour described in comment 3 is still an issue:

Saving a project state when no change was made produces an empty commit (commit with the provided message but no files).
Next, if I change e.g. artifact ID, only pom.xml is saved/added to the commit (since no file was changed in the previous step).
After that, if I e.g. add a KBase and save, the commit contains 2 changed files - .pom.xml (pom.xml was modified in the previous step) and kmodule.xml.
In the fourth step, I add some import suggestion and save, which gives me a commit with changes done to .kmodule.xml (kmodule.xml was modified in the previous step) and project.imports.
If I make another change in KBases section and save, I get a commit with .project.imports (project.imports was modified in the previous step) and kmodule.xml.

In other words:
If, in step N, I change file X (where X is one of pom.xml, kmodule.xml, project.imports) via the Project editor, in step N+1, the commit will contain also changed file .X. Each step consists of only one change in one of the [pom.xml, kmodule.xml, project.imports] files and saving the modification.
If there was no change to a file in step N, then in step N+1, the commit will contain only the modified file, as expected.

I'll retest with the next available build.
Comment 7 Toni Rikkola 2014-02-06 05:41:00 EST
(In reply to Toni Rikkola from comment #2)
> All the files with changes are now committed with a single commit when save
> is pressed.

Commits for this were:

Comment 8 Lukáš Petrovický 2014-02-07 11:19:18 EST
This no longer has a target release of 6.0.0.
Comment 10 Lukáš Petrovický 2014-03-13 09:28:06 EDT
Looking at the Git repos after our test runs, this no longer seems to be an issue. VERIFIED with ER2.

Note You need to log in before you can comment on or make changes to this bug.