开发者

SVN Synchronize vs Update to Head (subclipse)

开发者 https://www.devze.com 2022-12-19 01:56 出处:网络
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 tr

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 f开发者_JAVA百科or your response and taking the time to read this!


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消