I\'m fairly new to both Subversion and Subclipse and am seeing some issues that lead me to believe there is a difference between updating to head, and synchronizing. Specificall
There is a difference. When you use the Synchronize view, only the items in the view are updated. With Subversion, folders also have a revision that is bumped everytime a child is modified. However, since these do not appear in the view, they never get updated. When you do Team > Update on the project, all folders and files are updated to a single uniform revision. I have a couple of blog posts that explain this:
This one explains the core SVN concept of a mixed revision working copy, and is essential to understanding this:
http://markphip.blogspot.com/2006/12/mixed-revision-working-copies.html
The second shows a feature in Subclipse to deal with this:
http://markphip.blogspot.com/2006/12/subclipse-synchronize-feature-show-out.html
Since the second blog was written, most Subclipse users found they did not like this feature even though it helps with this problem. So it is now off by default in current versions. I do not think anyone uses it anymore.
The main thing is just to occasionally use Team > Update on your project to bring it all up to a single uniform revision.
Mark
I think your assumption that synchronizing is the same as updating to HEAD is false. If, in Subclipse parlance, "synchronize" means "commit," then it is certainly false because committing does not update your working copy. You have to explicitly update after you commit to be at HEAD.
Which brings me to your second question: I think the reason the bolded line is below other commits is because of the above reason—committing does not update. This means that you can commit a change to a file, and then look at another file and see it as being older than HEAD, because those other files have not also been brought to HEAD.
This article may help clear up this concept of mixed revisions: http://markphip.blogspot.com/2006/12/mixed-revision-working-copies.html
I also encourage you to familiarize yourself with the SVN documentation, as working with plugins and extensions for Subversion always becomes easier when you understand how the underlying SVN system works.