Saturday, October 08, 2005

The syncing crisis - going down for the third time!

So, with a clear path ahead of me, I start what I hope is the final work on implementing the 4 new code templates for eclipse.

But I run into enough trouble syncing that I'm dead in the water, and have to start coming up with as many puns as I can about "syncing" as opposed to "swimming..." (Did you get the "dead in the water" bit? Just checking...)

Where to start? I reviewed earlier episodes of this epic to see if I've described how I was working. Didn't find much useful. (I'll have to complain to the author...) The issue I've had is that I have never gotten the nightly builds to build successfully, so I've been taking downloads of the latest integs. Then, I'll go to the CVS Repository Perspective and download the source for the two projects I've needed so far (jdt.ui and jdt.ui.tests) and get the source that corresponds to the integ I've downloaded. (Note the org.eclipse.test.performance that Dirk admonished me I needed back in mid-September hasn't changed yet, so I don't need to update it.) You have to navigate these huge lists of versions for each eclipse package, and not all the versions avaiable on the website seem to be available in the CVS perspective. The CVS perspective is a few versions behind, especially if they are cranking out integs on the eclipse website. But, despite this, these versions always build just right, and the tests are green. (For those of you who aren't JUnit fanatics, this means all the automated tests pass.)

Life isn't exactly rosy working this way, because there is no function in eclipse to update from an integ version.

OK - one more digression just to make sure we understand each other... Working with CVS in the "normal" way, you don't check out files and lock them so other developers can't change 'till you're done. That wouldn't begin to work in the wild world of open source. You check out unlocked files, make changes, and then just before you integrate (which you do every time you run JUnit tests unless you're a degenerate loser) you "update" which is a one-way sync with the source repository. This way, if somebody has checked in new changes since you last checked out, you get them, merge them in with your changes, and then you can rerun your tests secure in the knowledge there aren't any nasty integration surprises lurking. If your tests run green, you check in, and let somebody else worry about the pain of merging.

OK OK, so back to why life ain't rosy. Since I haven't figured out how to successfully merge in the normal CVS manner with a new integ when I take one, how do I get the changes I've already made in the source merged into the new integ's version? The first thing I tried a long time ago was to get out of eclipse and use CVS directly to update to a label. This isn't as easy as it sounds, and involves delving into options having to do with the "sticky tag" that I don't think I got right. In any case, it resulted in one of those now familiar 200 compilation error states, so I wrote the whole thing off as a disaster and never tried again.

Next fallback? Brute force hacking. I got a new integ load of eclipse with source for my files and copied the changes in the 5 files I've made so far over using a file merge utility. As I mentioned in my 9/25 post, I've done this twice already at this point, and it is profoundly unsatisfying. As a matter of fact, it makes me feel like technological pond scum.

So the urge was strong to find the "real" way to do this. Eclipse committers can't be working this way - this is ridiculous. Thus my earlier questions to Martin, and his response about using the HEAD revision of the files I was changing plus a bunch of others. (This is presumably to catch all the changes from the likely places people are actively working, so all the changes stay in sync.) This seemed to make sense, and I was in a good enough state that my tests were all green, so I boldly used the "sync to repository" command in elcipse even though I wasn't entirely sure what it synced to (assuming HEAD) and did the merges of my changes in using functions in the "Team Synchronizing" section in eclipse.

BTW - Eclipse did a very good job with the synchronizing functions for file merging. These are better than any of the file merge utilities I was using. The usability of selecting each change and deciding whether to take the change or skip it, or which version should be the source for any particular change, or to just copy all the changes from one version to another are all great and less error-prone.

What I ended up with when I first did this had no compliation errors. I forgot to run the tests, but we'll cross that bridge shortly. So I figured there would be no problem with making some changes, syncing again and checking in, right? Slam dunk.

Imagine my chagrin when I made a bunch of changes and got the new 4 template version almost done, synced again, and a bunch of random compliation errors show up again. Now this is a problem. These errors look like half-implemented features or misaligned versions and they're not in the area I've been working in. Looks like I shouldn't try fixing them. So I can't get eclipse to build in this current state. Unless there's some other magic I am overlooking, my next instinct is to back up to my previous successful method, to sync up to an integ label.

Trouble is that before, I was always syncing from an earlier version to a later, but this time, I am going to want to extract my changes from a later version back into an earler version (HEAD to a last good integ). I can't imagine this is the way to go. I go back to earlier statements that this is ridiculous and something must be wrong here. There comes a time in every red-blooded male's life when he has to admit it's time to ask directions.

- - - - - - - - - -

Martin & Dirk,

Ran into some trouble synchronizing so I didn't get it done yet.
Will do it over the weekend.

Do you guys really sync to HEAD? Whenever I try there are always compilation
errors, so I can't get a clean build or test run.

I've been trying to sync to the last integ label, but the functions to do that
easily are missing from eclipse CVS support, and I haven't found the forumula
yet. (The "Team Synchronization" functions are cool, but I have only figured
out how to synchronize to HEAD.) I have been syncing using external tools, and
it's a pain.

So I can't use HEAD and I can't sync to an integ label. What am I missing?

- John

- - - - - - - - - -

As usual, Martin responded right away...

- - - - - - - - - -

John, no problem, there's no rush.
We work from HEAD with the plugins I listed, and -I forgot to say- always use
the latest integration build (I20050927-1200 currently) for the rest of the
plugins as binary (you automatically get these when you use this build to
develop with. If you are not, go to Preferences - Plug-in Dev. - Platform Target
to set the location to the latest I-build).
What are the errors you get?

- - - - - - - - - -

Hmm - Could this be the missing magic piece? When I did my last sync, I didn't update the underlying integ. If it changed out from under me between the two times I sync'ed to HEAD, that would explain why it worked the first time and not the second.

So I downloaded yet another Eclipse integ, and point my current mess over to it as Martin recommended above. There are still compliation errors. (Dang!) But not as many (Well, maybe...) Understanding that coding requires infinite patience, I look into these errors, and find they refer to files in the folders I'm synchronizing. Since I had to hand-select the files to synchronize, there's a chance I may have overlooked these. So I go back into CVS perspective, and make sure that I select every folder or file except the ones I changed and copy the latest version from HEAD over what's there.

Low and behold, the errors dissapear. I'm golden.

Next - the home stretch.


Post a Comment

<< Home