Skip to main content

[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



Back to the top