github
/
jgit
mirror of https://gitee.com/github-mirror-repo/jgit.git
1
0
Fork 0
Code Issues Releases Wiki Activity
纯java实现的git操作库。
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
2106 Commits
45 Branches
0 Tags
37 MiB
Tree: 7f7a3f9b78
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '7f7a3f9b78'
${ noResults }
jgit/org.eclipse.jgit.storage.dht/META-INF/MANIFEST.MF

27 lines
1.2 KiB
Raw Normal View History Unescape

Store Git on any DHT 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>
14 years ago
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: %plugin_name
Bundle-SymbolicName: org.eclipse.jgit.storage.dht
Prepare 2.1.0 builds Change-Id: I4aad3efdd435d8d5eb53c84a8d38132acce97c25 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
13 years ago
Bundle-Version: 2.1.0.qualifier
Store Git on any DHT 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>
14 years ago
Bundle-Localization: plugin
Bundle-Vendor: %provider_name
Prepare 2.1.0 builds Change-Id: I4aad3efdd435d8d5eb53c84a8d38132acce97c25 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
13 years ago
Export-Package: org.eclipse.jgit.storage.dht;version="2.1.0",
org.eclipse.jgit.storage.dht.spi;version="2.1.0",
org.eclipse.jgit.storage.dht.spi.cache;version="2.1.0",
org.eclipse.jgit.storage.dht.spi.util;version="2.1.0",
org.eclipse.jgit.storage.dht.spi.memory;version="2.1.0"
Store Git on any DHT 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>
14 years ago
Bundle-ActivationPolicy: lazy
Bundle-RequiredExecutionEnvironment: J2SE-1.5
DHT: Replace TinyProtobuf with Google Protocol Buffers 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>
14 years ago
Import-Package: com.google.protobuf;version="[2.4.0,2.5.0)",
Prepare 2.1.0 builds Change-Id: I4aad3efdd435d8d5eb53c84a8d38132acce97c25 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
13 years ago
org.eclipse.jgit.errors;version="[2.1.0,2.2.0)",
org.eclipse.jgit.generated.storage.dht.proto;version="[2.1.0,2.2.0)",
org.eclipse.jgit.lib;version="[2.1.0,2.2.0)",
org.eclipse.jgit.nls;version="[2.1.0,2.2.0)",
org.eclipse.jgit.revwalk;version="[2.1.0,2.2.0)",
org.eclipse.jgit.transport;version="[2.1.0,2.2.0)",
org.eclipse.jgit.treewalk;version="[2.1.0,2.2.0)",
org.eclipse.jgit.storage.file;version="[2.1.0,2.2.0)",
org.eclipse.jgit.storage.pack;version="[2.1.0,2.2.0)",
org.eclipse.jgit.util;version="[2.1.0,2.2.0)",
org.eclipse.jgit.util.io;version="[2.1.0,2.2.0)"