After committing all changes to my SVN repository, I always see "incoming change" on my folders.
I have found similar posts here on StackOverflow, but none ended with a solution. Someone did mention that their repository was set up incorrectly, but did not elaborate.
Any ideas where I can begin investigating?
I am using Juno Service Release 1 Build id: 20120920-0800 and SVN version 1.6 with the following plug-ins:
You must have the Subclipse feature to Show Out of Date folders turned on (it is not on by default). This blog post describes the feature:
http://markphip.blogspot.com/2006/12/subclipse-synchronize-feature-show-out.html
I generally do not recommend using it, which is why the preference is off by default.
Related
I've looked at the answers to similar questions here, and none fit the bill, or manage to solve the issue.
Using Eclipse Neon.3 (4.6.3) with EGit 4.7.0, and no other versioning system like SVN or CVS, calling Team > Synchronize on some of my Java projects, which have been synced with a Bitbucket repo many times over, and which show absolutely no changes whatsoever in the compare editor, including any whitespace differences, Eclipse still lists several .java source files as Outgoing changes under the "Java Workspace" model.
So for instance, calling Team > Synchronize on a project in my workspace, that is tracked in my local Git repo and remotely in a Cloud hosted Bitbucket, returns the following message:
There are no more Incoming/Outgoing changes for Git Commits. However Java Workspace has changes in Incoming/Outgoing mode.
Change to Java Workspace
Show All Models
A Google search for "However Java Workspace has changes" only yields a single result:
The sole hit is a reported bug in Subversive (one of the two main SVN integrations for Eclipse). However, while the described issue sounds like a rather accurate match of the issue I'm having, it claims that doing another Team > Synchronize, or restarting Eclipse would resolve the phantom Outgoing changes. Not so in my case, not with EGit.
Like I said, the remote and local files are exactly the same, incl. their whitespace/line endings.
Fetch/Pull from origin says there are no changes, everything is up to date.
Calling Replace With > HEAD Revision also doesn't help, Eclipse keeps insisting, that my workspace has Outgoing changes. Outgoing where?
This is obviously no big issue, merely an irritating nuissance. Still would be nice to get to the bottom of it.
...Did you try doing the Eclipse dance?
Edit: I find after some time Eclipse will behave strangely (example: dumping views I have enabled, losing track of files, or behaviour similar to what you are experiencing). When this happens I usually select and delete the project from my workspace, close Eclipse, reopen it and reopen the project.
I don't know why this happens or why this works as a fix.
I can't seem to find this in the documentation. I need to be able to set a numerical ID with each commit...
Does anyone know if this is possible?
And if so, how can I enable this in EGit?
References to bug tracking systems are usually put into the commit message.
Some project only include the number, see the following EGit commit for an example. The "Bug: 406542" in the commit message is a reference to Eclipse bug 406542.
Other projects put the full URL to the bug report into the commit message.
I'm using: Eclipse Juno with Mylyn, SVN Subversive Plugin, Bugzilla 4.2.4.
I strive for the overall goal to loosly relate SVN commits with bugzilla tasks. Thanks to Mylyn I retrieve a great deal of information ready to be attached to the commit description. Good so far.
However, I wish to add the version that a bug is related to, to the commit description. In Eclipse, we may add task variables (Window, Preferences, Mylyn, Team, Commit Comment Templates). By default there is: ${task.status} - ${connector.task.prefix} ${task.key}: ${task.description}
${task.url}
Unfortunately there is no such thing like ${task.version}. Is there a workaround to add the Bugzilla version of the bug to the commit description?
thanks heaps,
What are the similarities and differences in functionality and project leadership between the two MercurialEclipse plugins that are currently (November 2012) available in the Eclipse Marketplace?
Just to expand on the question a bit:
I just want to use the working copy of a Mercurial project within Eclipse, but when I look for a Mercurial plugin I face this confusing choice. I suspect that for the moment it doesn't matter very much which I use. But of course I don't know that for certain.
At present (November 2012), there's a MercurialEclipse listed among products on Intland Software's web site, present in the Eclipse Marketplace as "MercurialEclipse (was: HgEclipse)", with a home page at JavaForge.com. There's another MercurialEclipse in the Eclipse Marketplace as "MercurialEclipse" that is more popular by downloads since August and that has a home page at BitBucket.org.
I see that there's shared history, but at present, looking at JavaForge and BitBucket, they list different version numbers (1.9.1 and 2.0.1 respectively) and different Eclipse update sites. I see that the codebase has diverged and reunited before (http://andrei.gmxhome.de/mercurialeclipse/index.html). Do we now have two sites for two stages in the same line of development? Or is there perhaps a rivalry (whether intentional or unintentional) in which I'll have to choose a side? In that case, does someone here have at hand the relevant information for choosing?
The short answer is they are the same with the Javaforge site lagging behind the Bitbucket site in releases. All bugs should be files on the Bitbucket site: https://bitbucket.org/mercurialeclipse/main
Originally MercurialEclipse was hosted on Bitbucket. Around the 1.5 release if I remember correctly Intland forked it to Javaforge. This is where the name HgEclipse originated. After some time the project reunited on Javaforge. Some time later just before the 2.0 release the project moved back to Bitbucket. There are a few reasons for moving back to bitbucket. One of them being that Intland did not do releases promptly and this caused confusion with users. Another reason is the JavaHg is hosted on Bitbucket and Bitbucket is otherwise a nice host.
Even though Intland has not directly contributed in a while I think they are still interested in hosting releases. Their update site includes Mercurial binaries whereas the Bitbucket one currently doesn't.
I'm using eclipse and Subversion (SVN) is my new version control.
Till now I used to use Concurrent Versions System (CVS) as my version control and after deploy operation I used to tag my projects with Tag as Version in eclipse like this:
Team --> 'Tag as Version..' --> Version-X-Y-Z
How can I do it now using SVN?
Normally, SVN has three root level directories,
trunk
tags
branches
In SVN server, for each project, you have the same above directory structure.
'trunk' is where you keep your ever developing code base.
'tags' is used for the same purpose that you've indicated. i.e. for versioning.
'branches' is used for things like feature developments/individual development.
An example,
Let's say I am developing a database synchronization application which will go out as Pilot release, Moonshine release, Kilimanjaro release, Great release and onwards..
I start in 'trunk' and continue my development for let's say 2 months at which time I am ready for Pilot release..
Then I create a 'tag' of the 'trunk' which I can name 'Pilot tag' which will be released to customers..
Now my main feature developments for next release which is 'Moonshine release' will continue in the 'trunk'. If their are any immediate bug fixes or show-stoppers in my 'Pilot release' those will be done in the 'Pilot tag' and released to the customers immediately..
However since the above fixes are not in my 'trunk' code, sometime later (before releasing the Moonshine release) I will 'merge' the modifications done in my 'Pilot tag' back to 'trunk'.
Here, there can be conflicts since the same code lines could have been modified in both 'Pilot tag' (for bug fixing mentioned earlier) and in 'trunk' (for feature modifications/development of new release). In this situation, you have to carefully review the conflicts, edit any such conflicts and accept the changes.
TortoiseSVN is the primary client tool for using SVN. It embeds features directly to your Windows right click menu for all above mentioned functionalities like commit, update, merge, branch (i.e. tag or branch) etc.
And for conflict resolution I personally prefer 'Beyond Compare' which is a third party application which you have to buy. You can setup TortoiseSVN to invoke Beyond Compare as the application for conflict resolution and it is far better and user-friendly than the built in conflict editor in TortoiseSVN tool.
You would need to install an Eclipse Subversion plugin like subclipse or Subversive. This will provide the same facility as that available for CVS.
For instance, here is the documentation on how to tag using Subversive.
To TAG, using Eclipse with SubClipse:
select Team, Branch/Tag, then click the 'select' button and drill into the appropriate project, then click 'tags' directory, and drill down to your last tag name or any similar name you plan on creating.
The full URL is copied into bar, then you can edit it changing the rightmost tag name portion to any new tag name.
Click next, select from HEAD (HEAD is referring to the repo path you have established already on previous page so in fact may be the Head of a Branch).
Enter a comment like 'tagging <appName> Release <for reason> version x.y.z'
Finish -
You can prior to this point or after, open the Eclipse 'SVN Console' from dropdown on right bottom of page, and see most recent SVN commands generated and there results.
Every checkin in SVN creates an new revision number. SVN revision number should be equivalent of your tag. Remember the SVN revision number for the production build.
Tagging and branching in Subversion works differently from CVS. In Subversion, "to create a tag" means to copy a revision (typically HEAD, but it can be some other revision) to a new directory within the "tags" directory. That is why, when you go to Team->Branch/Tag..., Eclipse is asking you for a URL to copy to.
Check out this page for a more detailed explanation of tagging in Subversion.
To help you understand how things are done "the SVN way," I'd recommend practicing Subversion usage from the command line, before trying it on Eclipse. Or, if not, at least open an SVN console in Eclipse to see the commands that it runs--you'll see that the tagging operation is indeed an svn copy.