Gource
Gource copied to clipboard
acaudwell
Some Deleted Files Still Appear in Gource Generation
Like the issue title says some files still appear in Gource generation even though the file has been deleted before like this file here. 
Sometimes when I run the generation, the file is gone like is supposed to be.
Same for me. I added some debug output for a file, causing this problem, here:
https://github.com/acaudwell/Gource/blob/9207043c9b051387fc7bf6fe1f426c3626b8217e/src/gource.cpp#L1244
std::cout << cf.action << " " << username << " " << t << " " << file->fullpath << std::endl;
Result was:
M UserA 325.219 /Path/Example.txt
D UserB 325.432 /Path/Example.txt
I think the modification short before the deletion through a different user keeps the file alive. Timestamps of the commits:
1502868789 - Wednesday, 16. August 2017 07:33:09
1502954369 - Thursday, 17. August 2017 07:19:29
I used seconds-per-day=0.25 for this run. When I change this value to 1, some files are "fixed" but some other files keep alive, that should be deleted. Maybe the users are not synchronized in the right way?
A log file and settings that produce the issue would help debug this. It might be getting removed from the pending deleted files in RFile::touch(), though its already quite aggressive at removing pending actions against a file if its getting removed: https://github.com/acaudwell/Gource/blob/9207043c9b051387fc7bf6fe1f426c3626b8217e/src/file.cpp#L249
AusweisApp2-bug.log gource-bug.txt
gource --load-config ./gource-bug.txt ./AusweisApp2-bug.log
In Line 66 +android/+tablet/ProviderDetailView.qml is deleted but its still visible in the simulation.
Maybe I was on a wrong way. Using the data from my comment before, I no longer get the line starting with D when I use the debug output from https://github.com/acaudwell/Gource/issues/122#issuecomment-421778275. addFileAction is never called for +android/+tablet/ProviderDetailView.qml.
Found the problem. lastline was never used for hg commits so the first file of every commit was ignored.
@FallenEXP @xorz57 : You are using Mercurial too?
I was happy too soon. #177 fixes the problem for the sample data I provided. But in the full environment the problem is still there in every 2nd run.
With https://github.com/SmallLars/Gource/commit/814e2d7df76f8e3c8875b58b5fa50494ee923867 I got a debug output:
/resources/qml/provider/+android/+tablet/ProviderDetailView.qml 269.270569 0.000000 /resources/qml/provider/+android/+tablet/ProviderDetailView.qml 323.011902 0.000000 /resources/qml/provider/+android/+tablet/ProviderDetailView.qml 325.427734 0.000000 /resources/qml/provider/+android/+tablet/ProviderDetailView.qml removed at: 325.427734 /resources/qml/provider/+android/+tablet/ProviderDetailView.qml 323.750977 325.427734 /resources/qml/provider/+android/+tablet/ProviderDetailView.qml 325.247803 325.427734
So un expire did not happen, but the file is still visible. I think we need to search on an other position.
Finally I found the problem. #178 is a suggestion to solve it.
https://github.com/acaudwell/Gource/issues/122#issuecomment-421778275 was the right assumption. The touch by a user could be processed after the delete of an other user, even if that is not the order given by the timestamps. On every touch fade_start was reset and leads to an interruption of the expiring process -> The file never expired.
Nice work. Had the same issue when I tried the test data but it illuminated a big issue with the Mercurial parsing.
I finally made a test case that triggers it with the default settings:
1277787454|alvin|A|path/to/file.txt 1277787454|alvin|M|path/to/file.txt 1277787454|alvin|M|path/to/file.txt 1277787454|alvin|M|path/to/file.txt 1277787454|alvin|M|path/to/file.txt 1277787454|alvin|M|path/to/file.txt 1277787454|alvin|M|path/to/file.txt 1277787454|alvin|M|path/to/file.txt 1277787454|alvin|M|path/to/file.txt 1277787454|alvin|M|path/to/file.txt 1277787454|alvin|M|path/to/file.txt 1277787454|alvin|M|path/to/file.txt 1277787454|alvin|M|path/to/file.txt 1277787454|alvin|M|path/to/file.txt 1277787454|alvin|M|path/to/file.txt 1277787454|alvin|M|path/to/file.txt 1277787455|bob|D|path/to/file.txt
It seems to need quite a lot of actions queued up for it to happen.
I'm having this issue with four files in my repo. The four files existed in two branches of my repo, and was deleted in one. Then I merged the two branches together, and deleted the files again when resolving merge conflicts.
The specific commit is https://github.com/Gamebuster19901/halomod/commit/908113309aa442e657a598b16227e5b7aaf32b79
And the files that were deleted but are still shown in gource are:
- https://github.com/Gamebuster19901/halomod/blob/5ee66446c2517fd018407a2bdffba00a8b379075/src/main/java/com/gamebuster19901/example/Main.java
- https://github.com/Gamebuster19901/halomod/blob/5ee66446c2517fd018407a2bdffba00a8b379075/src/main/java/com/gamebuster19901/example/proxy/ServerProxy.java
- https://github.com/Gamebuster19901/halomod/blob/5ee66446c2517fd018407a2bdffba00a8b379075/src/main/java/com/gamebuster19901/example/proxy/Proxy.java
- https://github.com/Gamebuster19901/halomod/blob/5ee66446c2517fd018407a2bdffba00a8b379075/src/main/java/com/gamebuster19901/example/proxy/ServerProxy.java
@Gamebuster19901
In the above case I think its a problem in how git log reports on the resolution to merge conflicts in merge commits. If you deleted a file in resolving a merge conflict it's not reflected in the list of file changes output by git log, so it's seeing example/Main.java being modified and re-adding it.
The best method to solve this problem that I found is to just linearize your git history first with
git filter-branch --parent-filter 'cut -f 2,3 -d " "'
before you run gource. This will just avoid any kind of problem with files not disappearing due to merge commits.
ATTENTION: Do this with a fresh checkout, not with something you are working on!
