Linear time about gource HOT 6 OPEN

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.

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.

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?

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

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.)

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!