Linear time

[GoogleCodeExporter]

What steps will reproduce the problem?
1. run with -s 0.0001 --disable-auto-skip

What is the expected output? What do you see instead?
Fast days and linear time. What I see is pretty arbitrary timelaps. The 
animation is nice, but it has little relation to the perceived time.

What version of the product are you using? On what operating system?
0.25 Windows binary

Please provide any additional information below.
I'm trying to create a video with the progress of a repository since 1994. 
I want the video to be 5min long, with linear time from start to finish. It 
seems to be hard to achieve this, given the irratic time jumps depending on 
commit activity.

Is perhaps the --disable-auto-skip option failing?

Original issue reported on code.google.com by mstormo@gmail.com on 5 Mar 2010 at 10:05

[GoogleCodeExporter]

I'm looking to do the same thing.  Bursts in project activity from a time 
perspective are visually interesting, but require constant "velocity", if you 
will.

Original comment by cmpilato on 27 Jul 2010 at 6:25

[GoogleCodeExporter]

I think the problem here is the commit history you're giving Gource is not 
completely chronological, but jumps backwards and forth (eg someone may merge a 
branch into the main trunk adding a lot of commits which were done weeks or 
months before), and therefore the clock jumps back and forth or appears to 
stall.

Since Gource reads the history incrementally, it cant sort the entire history 
first to be entirely chronological without doing a lot more work. I suppose it 
might be useful to support an option where by Gource can read the entire log, 
convert it to the Gource 'custom log' format, and play it. It might also be 
useful to allow outputing a log in this format for the user to sort/modify 
themselves as it may be more easy to work with than the raw commit history 
produced by the VCS.

You may also want to try --max-file-lag option which controls how many seconds 
of user time a change can lag behind when it was due to appear.

Original comment by acaudw...@gmail.com on 27 Jul 2010 at 11:00

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Logs are chronologically ordered in my case.  (They come from Subversion, by 
way of svn-gource.log.)

I (naively) assume that Gource needn't read-ahead any more than a single day's 
log messages, figure out how many frames are allotted to plot that day's 
activities (based on the -s and --output-framerate option values), and then 
ensure that it does said plotting within that frame allotment.

I've not explored --max-lag-time.  Out of curiosity, what would make a change 
lag behind its due-to-appear moment?

Original comment by cmpilato on 4 Aug 2010 at 8:08

[GoogleCodeExporter]

Hi,

I think the key issue is that file changes in Gource don't happen instantly at 
the time of the commit, rather the user moves into proximity of the directory 
of the file and casts a ray. max-file-lag limits how long the user can take to 
get to the directory to do this. If the time runs out the file will just appear 
and a ray will shoot out from the user regardless of how far away they are. The 
default is 5 seconds of actual time.

The fact that things don't happen instantly at the time in the log, and the 
time it takes a user to make file changes depends on the current constantly 
changing layout of the tree (and to make it even harder they don't move in 
straight lines), makes it difficult to compute how long a user is going to take 
to do something.

It might be more elegant if the users 'metabolic rate' increased as it got 
behind on its work rather than the current 'shooting out rays' solution to the 
max-file-lag problem.

Cheers

Andrew

Original comment by acaudw...@gmail.com on 4 Aug 2010 at 9:51

[GoogleCodeExporter]

At first glance, it looks like keeping an obnoxiously low '--max-file-lag' 
value is helping.  (And thanks for indulging my curiosity in your explanation.)

Original comment by cmpilato on 5 Aug 2010 at 1:14

[GoogleCodeExporter]

Actually it has really cool visual effect:  Laser blasts from off screen 
followed by a user rushing in towards its target!  Thanks to Gource, I'm 
getting my Star Wars on!

Original comment by cmpilato on 5 Aug 2010 at 1:15