This reverts commit bf845c126d since this
change needs to go through a formal IP review and Chris missed to file a
CQ for that.
Change-Id: I303515d78116f0591a2911dbfb9f857738f086a9
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This section contains the names of the current committers
and is required for acceptance to the Maven Central repository
Change-Id: Ib758cfe0a574aa3e80af9d289bec1a74d9b78d25
In order to generate API reports run: mvn clirr:clirr
The reports are generated to the folder
target/site/clirr-report.html under the respective
project.
In order to check API compatibility and fail the build
on incompatible changes run: mvn clirr:check
For now we compare the API against the latest release
1.1.0.201109151100-r.
Bug: 336849
Change-Id: I21baaf3a6883c5b4db263f712705cc7b8ab6d888
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Signed-off-by: Kevin Sawicki <kevin@github.com>
The standard Google distribution of Protocol Buffers in Java is better
maintained than TinyProtobuf, and should be faster for most uses. It
does use slightly more memory due to many of our key types being
stored as strings in protobuf messages, but this is probably worth the
small hit to memory in exchange for better maintained code that is
easier to reuse in other applications.
Exposing all of our data members to the underlying implementation
makes it easier to develop reporting and data mining tools, or to
expand out a nested structure like RefData into a flat format in a SQL
database table.
Since the C++ `protoc` tool is necessary to convert the protobuf
script into Java code, the generated files are committed as part of
the source repository to make it easier for developers who do not have
this tool installed to still build the overall JGit package and make
use of it. Reviewers will need to be careful to ensure that any edits
made to a *.proto file come in a commit that also updates the
generated code to match.
CQ: 5135
Change-Id: I53e11e82c186b9cf0d7b368e0276519e6a0b2893
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
jgit.storage.dht is a storage provider implementation for JGit that
permits storing the Git repository in a distributed hashtable, NoSQL
system, or other database. The actual underlying storage system is
undefined, and can be plugged in by implementing 7 small interfaces:
* Database
* RepositoryIndexTable
* RepositoryTable
* RefTable
* ChunkTable
* ObjectIndexTable
* WriteBuffer
The storage provider interface tries to assume very little about the
underlying storage system, and requires only three key features:
* key -> value lookup (a hashtable is suitable)
* atomic updates on single rows
* asynchronous operations (Java's ExecutorService is easy to use)
Most NoSQL database products offer all 3 of these features in their
clients, and so does any decent network based cache system like the
open source memcache product. Relying only on key equality for data
retrevial makes it simple for the storage engine to distribute across
multiple machines. Traditional SQL systems could also be used with a
JDBC based spi implementation.
Before submitting this change I have implemented six storage systems
for the spi layer:
* Apache HBase[1]
* Apache Cassandra[2]
* Google Bigtable[3]
* an in-memory implementation for unit testing
* a JDBC implementation for SQL
* a generic cache provider that can ride on top of memcache
All six systems came in with an spi layer around 1000 lines of code to
implement the above 7 interfaces. This is a huge reduction in size
compared to prior attempts to implement a new JGit storage layer. As
this package shows, a complete JGit storage implementation is more
than 17,000 lines of fairly complex code.
A simple cache is provided in storage.dht.spi.cache. Implementers can
use CacheDatabase to wrap any other type of Database and perform fast
reads against a network based cache service, such as the open source
memcached[4]. An implementation of CacheService must be provided to
glue this spi onto the network cache.
[1] https://github.com/spearce/jgit_hbase
[2] https://github.com/spearce/jgit_cassandra
[3] http://labs.google.com/papers/bigtable.html
[4] http://memcached.org/
Change-Id: I0aa4072781f5ccc019ca421c036adff2c40c4295
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In order to run the static checks run:
mvn -P static-checks clean install
Change-Id: I14077498a04be986ded123ddbfc97da8f9bc3130
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
It fixes 'Corrupted MAC on input' ssh issue.
CQ: 4728
Change-Id: I7de63cb3482488ac938566706edebee8a1cdad3a
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
Set the plugin version in the top-level pom, not the unit test pom.
This ensures the same plugin is used for all JUnit tests within the
overall project.
Drop the include **/*Test.java definition, as its no longer necessary
with the JUnit 4 based test suite. All of the test classes now end
with "Test" and include @Test annotations on the test methods.
Change-Id: Ib2c180bf531e1a97e31979fcc281fa0fc5a1abb3
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Matthias Sohn
Tomasz Zarna
Kevin Sawicki
Shawn O. Pearce
Chris Aniszczyk
Anatol Pomozov
Robin Rosenberg