[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[stellation-res] TClient Status; Bugs in Core Code
|
Hi,
I'd like to communicate the current status of the T-client work along with
some bugs in the core repository code that were discovered during the
t-client work.
Basic low-level merge functionality is now integrated into the T-client.
I am porting the first four (at least) of the CLI unit tests into Eclipse
JUnit tests, to verify merge functionality.
(These tests are Ant-driven command-line tests, located in
org.eclipse.stellation.repos.test and named 01.xml .... N.xml.)
The first two tests have been ported, and the T-client now passes those tests.
While porting the third test, I found a problem in the core merge code.
In comparison to the CLI code, the t-client performs additional integrity
checks while maintaining its internal data structures. This explains why
the CLI passed this unit test successfully, while the t-client fails the
test when it detects a dangling reference generated by the merge
code. Full details are in Bugzilla item #53123 "Merge produces
CompoundArtifacts with dangling references". A fix for this problem is in
progress (thanks, Mark!).
Sometime previously, I also found some bugs in the ZipUtils and BranchImage
classes. These bugs do not affect the CLI client, because they only occur
when a client performs multiple operations in a single session. Since the
CLI client never performs more than one operation at a time, and all
internal data structures are rebuilt when the CLI client is launched,
problems caused by these bugs are silently corrected when the CLI
restarts. Full details are in Bugzilla #53119 "Invalid BranchImage when
project is created and populated in a single operation".
It's possible that the fix for #53119 may break the existing CLI client
code. Therefore, I'd like to defer fixing this bug in the main branch code
(and the running server code on stellation.eclipse.org) until it's time to
deploy the Eclipse T-client and retire the CLI client.
The T-client should be ready for testing with several local developers
(Mark, Annie, myself) around the end of this week, using an internal test
server running the upgraded server code. It shouldn't take long to shake
out and fix the initial crop of bugs, after which we can post updated
source for the T-client and server, and upgrade the server on
stellation.eclipse.org. If one of the other committers wants to try out
the T-client with their own local server, I can make source drops available
when we deploy the new code here at Watson. (Bear in mind that the
T-client code requires Eclipse R3M7.)
As Mark's mentioned previously, the initial T-client merge functionality is
very crude. Immediately after the T-client is deployed, I will continue my
work to integrate the T-Client with the new Eclipse R3
Synchronization/Compare APIs.
Since these APIs are still a moving target, it's likely that the T-Client
may soon require a custom-assembled Eclipse installation (i.e. the R3M7
milestone build augmented with more recent Sync / Team / Compare
components). Thus far, R3M7 seems less stable than several earlier
milestone builds. These stability issues are likely to get worse rather
than better, at least for the near term, given the probable need to use a
custom-assembled Eclipse installation as discussed. Therefore:
* Work on a Sync/Compare view for the T-client will probably be impacted by
platform stability issues
* The decision to deploy the enhanced T-client (once it's cooked) will
definitely be affected by platform stability considerations.
Regards,
Jim
--------------------------------------------------------------------
Jim Wright, IBM T.J. Watson Research Center
*** The Stellation project: Advanced SCM for Collaboration
*** http://www.eclipse.org/stellation
*** Work Email: jwright@xxxxxxxxxxxxxx ------- Personal Email:
jim.wright@xxxxxxx