SVN Synchronize vs Update to Head (subclipse)

Question

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. Specifically I find that when I try to revert (using the subclipse history), I often get a message saying "Cannot reverse merge a range from a path's own future history, try updating first". My synchronize should ensure that I have the 'head' version of all the files in my branch on the REPO, but doing an "Update to head" does fix the issue... so what gives? I've tried to check the SVN console to see what's changing, but it's not very verbose.

Ideas?

I have a second question, but I'm assuming the answer to the first will shed light on it. If you are curious and have time to read, I'll type it up as well. Here's the scenario... I've branched all my files from a "Production" tag, and have begun to work on my project. After a few commits, I check a changed file's history and notice that the 'bolded' version (according to documentation, this should be head) is below all my commits. It's as if what I have isn't head. But head is just the latest version of the project right? So what am I missing.

Thanks for your response and taking the time to read this!

Wyatan

Answer 1

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

Simonasimonds

Thanks @Mark! This and your linked blog posts definitely helped clear a few things up in my mind about SVN and Subclipse. – Chappell

Answer 2

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.

Moujik

Hey Mike, I took a look at that article, but I'm not exactly sure that applies. Although a commit doesnt update your working copy, a sync should. I see not only outgoing changes, but incoming. Wouldn't that be the same as updating? – Wyatan

Ahh, the answer is in that article but in the section about folders! When I commit a file, it's parent folder does not move up to my revision. It knows about the revision (is present in the history) but doesn't move up. The sync ignores this, but an Update to HEAD solves it. – Wyatan