to include multiple copies/renames of a directory.

      When selected path for the parent_svn, choose the best (longest)
      path among all possible candidates.

…le quote

      our custom formatter).

      Note that this parser cannot be used with Ohloh because it does
      not emit the SHA1 hash of modified blobs.

      This is sort of a hack, caused by using git-whatchanged to
      generate our git logs.

      Long-term, we should try to get away from git-whatchanged, but I
      couldn't find a combination of options to git-log that would
      provide the needed blob SHA1s for all of the changed files.

…resses.

      If a directory is renamed, and then the branch we are tracking
      is created within that directory *during the same commit*, then
      the parser would mistakenly think that the branch had been moved.

…acters

      New implementation requires only 2 shell commands (rather than 3).

Add the --include-merges flag to the `bzr log` command.
Old bzr 1.12 included merges by default; the upgrade requires the flag.

It is possible for Bzr to report that a file has been renamed
and then modified in a single commit.

This breaks Ohloh, because a 'modify' action triggers a
comparison between the old and new files -- but since this file
has also been renamed, the old file does not exist (at least not
where Ohloh expects it).

We adapt the Bazaar system to what Ohloh expects: A rename
becomes a simple delete and add, and any subsequent modification
is ignored.

Hg now sometimes returns a trailing "+" character after a revid.
We need to strip this away.

doing svn info on missing files. Existing code, e.g. deepen_diff(),
relies on this returning an empty result with a success code.

Resolves http://thechaw.com/ohloh_scm/tickets/view/19

Parse the author name as well as the committer name
from the Bzr log.

Add a guard to restrict_url_to_trunk() so that it will
not do any work if the URL already ends with /trunk

During production operation, we always force users to specify
a module name. During test our tests, we are using an empty string
as the module name.

CVSNT has varying behavior when the module name is left empty.
In some builds (Mac development machines), leaving out the module
name causes rlog to include the CVSROOT directory, while in other
builds (production machines) the CVSROOT directory is excluded.

The presence or absence of the CVSROOT directory causes a unit test
to pass or fail with different cvsnt builds.

The flaw here is in the test harness: it should not leave the module
name empty, and thus the CVSROOT directory should never be logged.

I have modified the test harness to specify the CVS module name
everywhere. I have modified the expected responses from CVS to
exclude the CVSROOT directory.

This is a backport of Ohloh commit a2d86034. It has been live in
production since Nov 2009, but was never applied to the lib/scm
repository.

This is a backport of Ohloh commit f9b0c4be, ticket OTWO-16.

This is a backport of Ohloh commit fa1c6f7d, OTWO-55

Backport of Ohloh commit 4341cd0c.

Rolls back 6851c5c and applies alternate fix. Unit tests now pass.

The error text returned by `hg cat` changed in recent hg builds.

This patch allows ohloh_scm to accept either old or new error text.

Rather than always return all commits on all branches, the GitAdapter
can now restrict its result to show only 'trunk' (--first-parent)
commits.

NOTE 1. This version of ohloh_scm will not work with Ohloh.

This patch introduces a change to the public interface, which has only
been implemented on the GitAdapter. All other adapters (and Ohloh
itself) must now be updated to match the new interface.

NOTE 2. This patch introduces the --always flag to git-whatchanged.

To correct the negative line count issue, Ohloh must now account merges,
and include the line count delta from a merge commit's first parent. So
as part of the work to fix OTWO-31, Ohloh will begin reporting merge
commits for the first time.

Previously, if a merge commit caused no changes at all to the code tree,
it would be excluded from the list of commits seen by ohloh_scm. Since
Ohloh ignored all merge commits anyway, this was OK. That will change.

It is confusing to return some merges (those that have code changes) and
not others (those that do not have code changes). Therefore, we will now
return *all* merge commits to Ohloh, and thus we use the --always flag.

All adapters now accept a hash of options as the sole parameter
to the commits() methods.

Ohloh testing revealed a bug in HgAdapter.each_commit().

I've added a unit test to cover the problem.

It is possible for a bzr revision-id to include a ':' character.
We've been using ':' as a parsing delimiter, so such revision-ids
caused problems. Fixed.

If a commit did not contain any changes at all, then the GitStyledParser
would fail to parse the commit.

When changes are present, `git whatchanged` inserts an extra newline.
When changes are not present, we don't get the changes listed, and we
also don't get the extra newline.

That newline was required to trigger the parser to advance states.

I've added an explicit newline in our log format string to guarantee
that we'll always get at least one newline. If we get two, that's OK.

At some point we should probably get rid of GitStyledParser completely,
and use something more reliable like `git cat-file` or `git
fast-export`.

…Fail fast.

…on that was caught and eaten before

Basically in a previous changed I removed an exception catch for 'Not a valid URL'. Turns out that the misc.rb is_directory() method relied on the exception being eaten.
This commit adds proper exception catching for this now exposed error message and handles it correctly.

If the user supplies a read-write Github URL, transparently substitute a
read-only URL. This avoids an unwanted (and unhandled) password prompt.

Whenever a git merge commit has a resulting tree identical to its
first parent's tree, the list of diffs should be empty.

However, a bug in our commit parser caused us to return the set of
diffs relative to the second parent, instead of the correct empty list.

I could not invent a method to force `git whatchanged` to do what we
want, so I surrendered, and instead I manually patch the result after
the fact.

We have always ignored 'fatal signal 11' when it is returned from
eclipse.org in response to a `cvs ls` command. We do this because
eclipse.org *always* returns this error, even when everything is OK.

As it turns out, more CVS servers than just eclipse.org do this. There
is probably a particular version or configuration of CVS that causes
this.

The result is that many CVS repositories cannot be processed by Ohloh
because we treat these errors as fatal.

Let's simply accept 'fatal signal 11' as standard operating procedure,
and always ignore it when it is returned by `cvs ls`.

This patch allows BzrAdapter to process repositories that include ghost
commits, and should also improve line count performance considerably.

BzrAdapter's cat_file_parent() was needlessly complicated. To determine
the revision ID of a parent commit, we would request the log for that
commit -- using the revision ID! -- and then parse the revision ID from
the resulting log fragment. This work was completely pointless.

Worse, in the case of a ghost commit, the parent commit is not actually
present in the repository. This would cause the log request to fail, and
thus cat_file_parent() would fail.

Ohloh doesn't actually care what the ghost commit contains; we were
trying to read it simply to find its ID (which we already know, and
worse, won't use). By removing the redundant ID lookup, Ohloh can
successfully process repositories that contain ghost commits.

I spent some time trying to create a test repostiory that includes a
ghost commit, but this is rather involved. You can't do it using the bzr
CLI alone. The most common source of ghost commits seems to be some
complex interaction with bzr svn-import.

I manually verified that this fix works with repository `lp:bzr` itself,
which has a ghost commit as a parent of revo 897.

Eg
  <modified>
    <file..
    <file..
  <modified>
  should create two diff records.

Yields merge commit on </log> tag and not </merge> tag.

Funny business with commit ordering has been fixed by BzrXmlParser.
Now, when we request that Bzr iterate commits in the '--forward' direction,
we correctly get the branch commits *before* the merge that brought them in.

After log parsing, commit messages don't have trailing newline anymore.

Adds bzr_with_nested_branches repository for tests that has two
level nested branching and merging.

… reading stdout/err immediately.

This adapter uses bzrlib via rubypython gem. Shelling out bzr commands
has a lot of overhead including Python interpreter startup for each
command. Getting data via bzrlib APIs is much faster.

bzr generates kind_changed entries when file-kind changes, e.g
symlink changed to a file. These entries are now completely
ignored. Tests are added for ignoring directory entries and
kind_changed entries.

…es).

cmd_* based adapter was leaking memory. Details are here -
https://answers.launchpad.net/bzr/+question/173096

This commit changes the BzrlibAdapter to use an out-of-process
Python process serving bzr commands. bzrlib_pipe_server implements
a command loop, where it expects commands on stdin, sends status/
control-info on stderr and actual data on stdout. BzrlibAdapter
acts as a client.

This commit changes the BzrlibAdapter to use an out-of-process
Python process serving bzr commands. bzrlib_pipe_server implements
a command loop, where it expects commands on stdin, sends status/
control-info on stderr and actual data on stdout. BzrlibAdapter
acts as a client.

…lls.

BzrXmlParser depends on bzr's xmloutput plugin. This plugin does not
emit authors. See the bug report for info -
https://bugs.launchpad.net/bzr-xmloutput/+bug/618307
We have patched the xmloutput plugin and have submitted a patch to
xmloutput plugin. Meanwhile, we'll deploy patched version on slaves.

OTWO-1023 - Bzr xml parser is omitting author attribute.

If the commit specified by the :after option was a merge commit, then
the BzrAdapter would incorrectly return some commits that precede the
:after commit.

Bzr does not natively support a "show me all commits after X" option.
Thus, we request all commits *beginning* with X, then attempt to remove
X itself from the result set.

The problem here is that if X is a merge commit, then the Bzr log will
include not just X but also all of the branch commits brought in by X.
These branch commits will be emitted by the BzrXmlParser before X.

So rather than simply delete X from the result set, we now delete X *and
all prior commits* from the result set.

Bzr ipc adapter

…he patched xmloutput plugin for bazaar

I renamed the readme file so that GitHub will display it nicely.