Open Stack

On Fri, Sep 23, 2011 at 8:33 PM, Stefano Maffulli <stefano at openstack.org> wrote:
> CVSanaly2. CVSanaly2 is a tool that extracts information out of source
> code repository logs and stores it into a database. It works well with
> git, so I fooled around with it on the nova, swift and glance
> repositories (see the attached plot, as an example).

Hey Stef!

Your graph shows an anomaly that I think should be discussed. Namely,
the graph outlines the total number of *BZR* commits, and is a bit
misleading when referring to actual trunk patches. Because local bzr
commit history is kept when merges are performed, the number of
commits in the graph is far above the number of patches to trunk. With
our move to Git, the Bzr to Git conversion *kept* this local commit
history. However, going forward, local commits are now *squashed*
during a rebase so that patches to trunk are a single commit unit (in
almost all cases). This will mean that the number of "commits" shown
in this graph going forward is likely to be cut down *dramatically*.
As an example, the number of actual patches to trunk in Nova is around
2000. However, the number of commits stored in the Git tree is >11K.
This is because the git conversion kept the local commit history from
Bazaar. This won't happen going forward, though, which means the graph
will look extremely skewed...

Let me try to explain further.

If I was working on a feature using the old system (bzr), I would do:

bzr branch lp:nova some-feature
cd some-feature
# Work in this branch, doing lots of this:
bzr commit -m "Small piece done"
... more work ...
bzr commit -m "More work done"
... more work ...
bzr commit -m "Even more work done"
... need trunk changes ...
bzr pull
bzr commit -m "merge trunk"
... more work ...
bzr commit -m "Final work done"
bzr push lp:~jaypipes/nova/some-feature

At this point, there would be 5 commits in the branch that I would
propose for merging into trunk. If accepted, there would be yet
another commit, representing the merge of this code into trunk PLUS
the 5 local commits I did, so 6 total commits.

In Git-land, the above would be *rebased* into a single changeset,
which would be pushed for review in Gerrit and accepted into trunk *as
a single commit*.

So, word of warning... I think we can safely assume that we should
start entirely from scratch in tracking commits under the new system.

Cheers!
-jay