Seems like File.copy doesn't do directories (as source, that is),
only files (as far as I can tell from reading the docs and trying
it in irb, punch me if I'm wrong). It only creates a zero byte file
in the target directory on my system.
Replaced File.copy with a system call to 'cp -R ...' to do the job.
Seems like FileUtils could have done it just as well (with cp_r),
but I figured making a system call was better than introducing a
new dependency.
This keeps the subviews in memory, which means that switching views will
be faster if a view has already been opened. This also allows you to type
a commit message, switch to the history view, and then switch back to
continue typing.
Previously, the diff hilighter was a bit odd in that it would
just search for elements with a diff and highlight those. While
useful in theory, this wasn't used at all. We change it to
receive the diff to hilight, which makes the code somewhat simpler.
A list of files included in a commit are listed below the
commit message. The list are links which will take you to
that file in the diff display below.
The title of each fileHeader is now just the path to the file
instead of the full diff command.
While the focus is in the commit ctrl-down_arrow and up_arrow
will navigate to to next and previous file in that commit.
This uses a normal c array to store parent sha's. That means that we
save a lot of room, as they are only 20 bytes rather than 40 + the cost of
an NSArray and the NSStrings.
We used to use NSObjects, which was really expensive, because for each commit
as many as 100 graphlines can be created. By preallocating them and not
using NSObjects in general, we gain a massive speedup
I'm not sure what this loop originally did, but it was buggy and doesn't
seem logical. Removing it speeds up the graphing a lot, so let's kill it.
We can always get it back later if necessary
This produces cleaner code and is also significantly faster
than the old obj-c code: linux-2.6 goes from ~8 seconds
to ~6 seconds.
Using the c++ code allows us to do easy optimizations
This adds a new target 'SpeedTest', which just loads in a repository
and displays how long it takes to load the revision. This is handy for
testing the speed of the revwalking mechanism
This limits the maximum number of lanes to 32, making the
graphing a lot faster. For example, linux-2.6.git takes only
30 seconds now, rather than >400
This wasn't used anyway. A good idea would be to create a new
branchcontroller that takes care of all these revs, rather than
letting PBGitRepository take care of that
Martin Svangren