abstract class BaseFetchConnection extends BaseConnection implements FetchConnection
Implementors of fetch over pack-based protocols should consider using
BasePackFetchConnection
instead.
Constructor and Description |
---|
BaseFetchConnection() |
Modifier and Type | Method and Description |
---|---|
boolean |
didFetchIncludeTags()
Did the last
FetchConnection.fetch(ProgressMonitor, Collection, Set) get tags? |
protected abstract void |
doFetch(ProgressMonitor monitor,
java.util.Collection<Ref> want,
java.util.Set<ObjectId> have)
Implementation of
fetch(ProgressMonitor, Collection, Set)
without checking for multiple fetch. |
void |
fetch(ProgressMonitor monitor,
java.util.Collection<Ref> want,
java.util.Set<ObjectId> have)
Fetch objects we don't have but that are reachable from advertised refs.
|
void |
fetch(ProgressMonitor monitor,
java.util.Collection<Ref> want,
java.util.Set<ObjectId> have,
java.io.OutputStream out)
Fetch objects we don't have but that are reachable from advertised refs.
|
available, close, getMessages, getMessageWriter, getPeerUserAgent, getRef, getRefs, getRefsMap, markStartedOperation, setMessageWriter, setPeerUserAgent
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
didFetchTestConnectivity, getPackLocks, setPackLockMessage
close, getMessages, getPeerUserAgent, getRef, getRefs, getRefsMap
public final void fetch(ProgressMonitor monitor, java.util.Collection<Ref> want, java.util.Set<ObjectId> have) throws TransportException
Only one call per connection is allowed. Subsequent calls will result in
TransportException
.
Implementations are free to use network connections as necessary to
efficiently (for both client and server) transfer objects from the remote
repository into this repository. When possible implementations should
avoid replacing/overwriting/duplicating an object already available in
the local destination repository. Locally available objects and packs
should always be preferred over remotely available objects and packs.
Transport.isFetchThin()
should be
honored if applicable.
fetch
in interface FetchConnection
monitor
- progress monitor to inform the end-user about the amount of
work completed, or to indicate cancellation. Implementations
should poll the monitor at regular intervals to look for
cancellation requests from the user.want
- one or more refs advertised by this connection that the caller
wants to store locally.have
- additional objects known to exist in the destination
repository, especially if they aren't yet reachable by the ref
database. Connections should take this set as an addition to
what is reachable through all Refs, not in replace of it.TransportException
- objects could not be copied due to a network failure,
protocol error, or error on remote side, or connection was
already used for fetch.public final void fetch(ProgressMonitor monitor, java.util.Collection<Ref> want, java.util.Set<ObjectId> have, java.io.OutputStream out) throws TransportException
Only one call per connection is allowed. Subsequent calls will result in
TransportException
.
Implementations are free to use network connections as necessary to
efficiently (for both client and server) transfer objects from the remote
repository into this repository. When possible implementations should
avoid replacing/overwriting/duplicating an object already available in
the local destination repository. Locally available objects and packs
should always be preferred over remotely available objects and packs.
Transport.isFetchThin()
should be
honored if applicable.
fetch
in interface FetchConnection
monitor
- progress monitor to inform the end-user about the amount of
work completed, or to indicate cancellation. Implementations
should poll the monitor at regular intervals to look for
cancellation requests from the user.want
- one or more refs advertised by this connection that the caller
wants to store locally.have
- additional objects known to exist in the destination
repository, especially if they aren't yet reachable by the ref
database. Connections should take this set as an addition to
what is reachable through all Refs, not in replace of it.out
- OutputStream to write sideband messages toTransportException
- objects could not be copied due to a network failure,
protocol error, or error on remote side, or connection was
already used for fetch.public boolean didFetchIncludeTags()
FetchConnection.fetch(ProgressMonitor, Collection, Set)
get tags?
Some Git aware transports are able to implicitly grab an annotated tag if
TagOpt.AUTO_FOLLOW
or
TagOpt.FETCH_TAGS
was selected and the
object the tag peels to (references) was transferred as part of the last
FetchConnection.fetch(ProgressMonitor, Collection, Set)
call. If it is possible
for such tags to have been included in the transfer this method returns
true, allowing the caller to attempt tag discovery.
By returning only true/false (and not the actual list of tags obtained)
the transport itself does not need to be aware of whether or not tags
were included in the transfer.
Default implementation of FetchConnection.didFetchIncludeTags()
-
returning false.
didFetchIncludeTags
in interface FetchConnection
protected abstract void doFetch(ProgressMonitor monitor, java.util.Collection<Ref> want, java.util.Set<ObjectId> have) throws TransportException
fetch(ProgressMonitor, Collection, Set)
without checking for multiple fetch.monitor
- as in fetch(ProgressMonitor, Collection, Set)
want
- as in fetch(ProgressMonitor, Collection, Set)
have
- as in fetch(ProgressMonitor, Collection, Set)
TransportException
- as in fetch(ProgressMonitor, Collection, Set)
, but
implementation doesn't have to care about multiple
fetch(ProgressMonitor, Collection, Set)
calls, as it
is checked in this class.