views:

2536

answers:

2

Hi all, 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!

A: 
Michael Hackner
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?
gergesi
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.
gergesi
+2  A: 

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

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