"Roger C. Soares" <rogersoares@xxxxxxxxxxxxxxxx> wrote: > > >Hmm. I didn't notice that, but at this point its so damn fast for > >me that I don't have the reflexes to really try and use the table > >before GenerateHistoryJob is complete. I'll have to add some sleeps > >in there to make it slow down its work and see if I can reproduce > >what you are describing. > > Yep, I noticed it while debuging and don't think it's very important. > I'm very happy with the current speed and it's also almost instant to > me. I think the lazy provider could be of some help in case someone is > reading from a slow nfs partition or something like that. It's very > border case thought. Actually I think the trick to use there is the "early output and restart" that C Git's rev-list and gitk learned about two months back. We don't do this in jgit yet and that means we have to produce _all_ commits before we can topologically sort them and return even the first commit. We should be able to produce results immediately and then force a reset and redraw of the table when we find the rare cases where topological sorting gets violated by honoring the standard commit date ordering. There aren't many such cases in git.git or linux-2.6.git. They only happen if clock skew is enough that folks are able to create multiple commits at the same time that are out of order according to topology. And remember that in the GUI we do wind up redrawing the table anyway as we add new items to the end of it. So its really no big deal to just reset everything and restart when we find the violations. Its on my list of things to add to the jgit machinary, but I'm also looking to get push[*1*] and merge implemented. I am reasonably happy with the performance of the History view, as its actually now usuable on real projects. So its time to add new features, rather than optimizing old ones. [*1*] Hopefully this is a successful GSoC 2008 project. ;-) -- Shawn. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
