These issues are know to exist in CollabNet
Connector Framework
1.0
.
- Conflicts in artifact data are not handled
- If two mapped artifacts are changed at the same time, the CCF picks up the one
for the tracker which gets its turn first, and overwrites the data on the target
artifact. The changes to the target artifact are rendered non-transportable in
future shipment cycles.
- Dependencies and associations are not shipped
- In SourceForge or some other system, it is possible to relate artifacts to each
other in a parent-child relationship or some other kind of dependency. Artifacts
may also be associated with other entities that are not tracker items. These
dependencies and associations are not shipped along with the artifact data.
- Deletion of artifacts is not supported
- If a source tracker artifact is deleted, the deletion event is not shipped to
the target tracker. So the target artifact that was mapped to the source
artifact is not deleted. Users are required to delete this artifact
manually.
- GUI configuration and mapping tools are not available
- There is no graphical user interface to set up the tracker and field
transformation mappings. Users are expected to be familiar with XSLT and the
configuration files to set up the mappings.
- Limitations of database and CSV file import/export scenarios
- The CSV file and database sample scenarios can only be used for backup and
restore purposes. Users cannot use these scenarios to continuously synchronize
tracker changes with a database or CVS file and vice versa.
- Limitations with shipment of artifacts that fail
- If an artifact shipment fails, other available source artifacts get shipped to
the target repository. Until there is some change in the source artifact that
failed, it does not get shipped to the target. If an artifact fails during
shipment, and there are no other artifacts available, the CCF keeps trying to
ship the failing artifact. It stops only when there is some other artifact that
gets successfully shipped to the target.
- Systems are constantly polled
- The CCF keeps on polling the configured systems for changed artifact data. The
default poll interval is set to 1 second to avoid chances of the mapped
artifacts getting into a delta conflict. Due to the low polling interval,
network traffic might be considerable. To control network traffic, it is
recommended that users increase the polling interval if required.
- During mass updates, the SourceForge SOAP APU skips some artifacts
- If the CCF polls a SourceForge tracker for changed artifacts during a mass
update operation of that tracker's artifacts, the SourceForge SOAP API has been
observed to skip some of the changed artifacts that are eligible for shipment.
See tracker artifact 36 for details.
- Shipping of huge attachments is limited
- Shipment of huge attachments is limited by the memory available on the machine
where the CCF runs. So you need to restrict the maximum attachment size in
accordance with the Java Virtual Machine memory.