Can't find the package "com.google.testing.suitebuilder" anywhere.

I've managed to gather up all the other library dependencies necessary to 
compile src/, but I can't find the dependency "com.google.testing.suitebuilder" 
anywhere online, so I can't compile tests/

from javac:
    [javac] [..]/other/moe-java-read-only/tests/com/google/devtools/moe/client/AllTests.java:5: package com.google.testing.suitebuilder does not exist
    [javac] import com.google.testing.suitebuilder.TestSuiteBuilder;

> ant jar
Buildfile: /Users/jason/ws/reference/MOE/build.xml

clean:
   [delete] Deleting directory /Users/jason/ws/reference/MOE/build

compile:
    [mkdir] Created dir: /Users/jason/ws/reference/MOE/build/classes
    [javac] /Users/jason/ws/reference/MOE/build.xml:33: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
    [javac] Compiling 153 source files to /Users/jason/ws/reference/MOE/build/classes
    [javac] /Users/jason/ws/reference/MOE/java/com/google/devtools/moe/client/repositories/Revision.java:12: error: cannot find symbol
    [javac] import com.google.gson.annotations.JsonAdapter;
    [javac]                                   ^
    [javac]   symbol:   class JsonAdapter
    [javac]   location: package com.google.gson.annotations
    [javac] /Users/jason/ws/reference/MOE/java/com/google/devtools/moe/client/repositories/Revision.java:24: error: cannot find symbol
    [javac] @JsonAdapter(AutoValueGsonAdapter.class)
    [javac]  ^
    [javac]   symbol: class JsonAdapter
    [javac] /Users/jason/ws/reference/MOE/java/com/google/devtools/moe/client/database/SubmittedMigration.java:8: error: cannot find symbol
    [javac] import com.google.gson.annotations.JsonAdapter;
    [javac]                                   ^
    [javac]   symbol:   class JsonAdapter
    [javac]   location: package com.google.gson.annotations
    [javac] /Users/jason/ws/reference/MOE/java/com/google/devtools/moe/client/database/SubmittedMigration.java:18: error: cannot find symbol
    [javac] @JsonAdapter(AutoValueGsonAdapter.class)
    [javac]  ^
    [javac]   symbol: class JsonAdapter

BUILD FAILED
/Users/jason/ws/reference/MOE/build.xml:33: Compile failed; see the compiler error output for details.

Total time: 1 second

 find build/classes/
build/classes/
build/classes//com
build/classes//com/google
build/classes//com/google/devtools
build/classes//com/google/devtools/moe
build/classes//com/google/devtools/moe/client
build/classes//com/google/devtools/moe/client/database
build/classes//com/google/devtools/moe/client/database/AutoValue_RepositoryEquivalence.java
build/classes//com/google/devtools/moe/client/database/AutoValue_SubmittedMigration.java
build/classes//com/google/devtools/moe/client/repositories
build/classes//com/google/devtools/moe/client/repositories/AutoValue_Repository.java
build/classes//com/google/devtools/moe/client/repositories/AutoValue_Revision.java

If you have an Hg repository in your project, you might run into authentication 
issues when Moe tries to clone the Hg repo in HgClonedRepository's 
cloneLocallyAtTip(...) method. Moe tries to clone an Hg repo anytime you try to 
create_codebase, change, or migrate with an Hg repository.

What happens is Moe runs "hg clone" on your repo, but when the repo asks for 
your username and password, Moe crashes instead of letting you enter them.

A temporary solution is to have in your ~/.hgrc a section as follows:

[auth]
moe.prefix = https://path/to/repo
moe.username = [email protected]
moe.password = password

The "moe" before the prefix/username/password can be anything as long as it is 
consistent among the three fields. Make sure the prefix is the same URL as the 
one specified in the moe_config for your Hg repository.

By putting your authentication info in the .hgrc, you shouldn't have to input 
it when "hg clone" is run.

What steps will reproduce the problem?

I just tried running a 'Moe magic' migration from a git repository which
had 126 commits to migrate. However, due to branching history, Moe
apparently needed to review 406 revisions. As there's no commandline
argument to override MAX_REVISIONS_TO_SEARCH, I had to run a modified
version of Moe in order to migrate.


Suggest either:
- Increasing MAX_REVISIONS_TO_SEARCH by at least an order of magnitude
- Providing a command line flag to override the default

Sometimes there may be a very large repository in HG & Git in which one wants 
to open source only one certain directory, such as a sub-project or particular 
library.

As far as I can tell, currently the only way to do this is to write a bunch of 
editors which delete all folders that aren't being open sourced. This is far 
from optimal, as fetching the other folders could be expensive operation, and 
writing scrubbers for very complicated (dozens of folders) repositories for 
every open source project is error prone. It would be easier to limit a 
repository to a certain path.


Enhancement: Sparse checkout

Include an optional "path" field in the repository JSON object in the config 
file:
"internal": {
  "type": "hg",
  "url":  "file:///home/mbethencourt/work/test_repos/hg_0",
  "project_space": "internal",
  "path": "subproject/libraryname"
},

* Without a "path", MOE falls back to old behavior (operating on entire repo).
* With a path, MOE tries to use "sparse" checkout feature. A "renamer" 
translator will still probably be used to make the layout match external layout.

Sparse checkouts would be implemented a little differently for each client:
* Git would use the sparse checkout feature ( 
http://blog.quilitz.de/2010/03/checkout-sub-directories-in-git-sparse-checkouts/
 )
* SVN would use either "--non-recursive" or "--depth empty", and then "update" 
or "--depth infinite" the specified path
* HG, unfortunately, does not seem to have a sparse checkout feature. It can 
still be imitated however by cobbling together a few commands.

What steps will reproduce the problem?

Try to 'Moe magic' a repository with > MAX_REVISIONS_TO_SEARCH (=400)
revisions to visit.

Results in NullPointerException in AbstractRevisionHistory.java:60,
specifically, `revision` is null in the following block of code:

        if (visited.size() > MAX_REVISIONS_TO_SEARCH) {
          throw new MoeProblem(String.format(
              "Couldn't find a matching revision for matcher (%s) in repo %s within %d revisions.",
              matcher,
              revision.repositoryName,
              MAX_REVISIONS_TO_SEARCH));
        }

I added HTTP support to MOE for the --project_config and --db paths.
With this patch, you can now do stuff like:

  java -jar moe.jar check_config --config_file http://server/project_config

This patch makes it so a company can use a simple REST API internally for 
maintaining projects, and not have to worry about everything necessarily being 
on NFS. It is backward compatible with old usage: if a path is given (without a 
file:// or http:// scheme specifier), it will assume it is a file.

Here is the patch:     https://gist.github.com/1158363





Additionally, I wrote two quick Python scripts for testing and/or reference for 
this new feature.

I wrote a tiny example HTTP server:
* https://gist.github.com/1158377
  moe_config_server.py is a simple example server that implements the
REST api just mentioned. It takes a single argument, which is the port it will 
run on (defaults to 8080). It serves up "./projects/[project_name]/config.js" 
and "./projects/[project_name]/moe.db"

To make calling MOE repeatedly, I wrote a tiny wrapper Python script:
* https://gist.github.com/1158379
moe.py wraps around the main MOE adding arguments based on what it finds in a 
JSON file, "~/.moerc". This saves the user from having to type --test_config 
and --db with every call, and works with the above example server. With moe.py, 
you can just do commands like "moe.py project_name check_config"

Moe Python sets mime types automatically for SVN
http://code.google.com/p/make-open-easy/source/browse/trunk/moe/svn.py

Moe Java should do this as well.

Tests in error: 
  testOneSubmittedMigration_equivalent(com.google.devtools.moe.client.directives.BookkeepingDirectiveTest): String index out of range: -1
  testHeadsEquivalent(com.google.devtools.moe.client.directives.BookkeepingDirectiveTest): String index out of range: -1
  testOneSubmittedMigration_nonEquivalent(com.google.devtools.moe.client.directives.BookkeepingDirectiveTest): String index out of range: -1
  testLongStderr(com.google.devtools.moe.client.SystemCommandRunnerTest): Running perl with args [-e, print STDERR ("*" x 17000)] returned 255 with stdout  and stderr Number found where operator expected at -e line 1, near "* x 17000"(..)
  testLongStdout(com.google.devtools.moe.client.SystemCommandRunnerTest): Running perl with args [-e, print ("*" x 17000)] returned 255 with stdout  and stderr Number found where operator expected at -e line 1, near "* x 17000"(..)
  testFileToString(com.google.devtools.moe.client.testing.InMemoryFileSystemTest): String index out of range: -1
  testSetLifetime(com.google.devtools.moe.client.testing.InMemoryFileSystemTest): An absolute path was expected: C:\tmp\moe_persistent_0
  testCleanUpTempDirs(com.google.devtools.moe.client.testing.InMemoryFileSystemTest): An absolute path was expected: C:\tmp\moe_persistent_0
  testWrite(com.google.devtools.moe.client.testing.InMemoryFileSystemTest): An absolute path was expected: C:\src
  testListFiles(com.google.devtools.moe.client.testing.InMemoryFileSystemTest): String index out of range: -1
  testIsDirectory(com.google.devtools.moe.client.testing.InMemoryFileSystemTest): String index out of range: -1
  testCopyFile(com.google.devtools.moe.client.testing.InMemoryFileSystemTest): String index out of range: -1
  testMakeDirs(com.google.devtools.moe.client.testing.InMemoryFileSystemTest): An absolute path was expected: C:\a\b\c\d
  testMakeDirsForFile(com.google.devtools.moe.client.testing.InMemoryFileSystemTest): An absolute path was expected: C:\a\b\c\d
  testFindFiles(com.google.devtools.moe.client.testing.InMemoryFileSystemTest): String index out of range: -1
  testGetResourceAsFile(com.google.devtools.moe.client.testing.InMemoryFileSystemTest): An absolute path was expected: C:\tmp\moe_resource_extraction__0\test_resource
  testExists(com.google.devtools.moe.client.testing.InMemoryFileSystemTest): String index out of range: -1
  testIsFile(com.google.devtools.moe.client.testing.InMemoryFileSystemTest): String index out of range: -1
  testGetTemporaryDirectory(com.google.devtools.moe.client.testing.InMemoryFileSystemTest): An absolute path was expected: C:\tmp\moe_pineapple_0