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.
Related
Ok so we are trying to move from SVN (VisualSVN Server in house) to GitHub and we want to keep version numbers, all the posts so far I have tried to follow don't seem to find the version numbers. And I end up getting this 'Unable to determine upstream SVN information from HEAD history'
So we used the GitHub import utility to bring over the SVN repository but everything I have tried after that doesn't seem to work to allow us to access version numbering from SVN.
If anyone can help me please, I am not really great in either SVN or GitHub and all advice would be very welcome.
What do you mean by "we want to keep version numbers"? - The version info from SVN (revision numbers I think they call it) we need for historic records (we are getting rid of SVN) it would be great to see them as a message in the commit comments for historic SVN items. I may be using the wrong terms sorry.
I am not really great in either SVN or GitHub
Hire anybody proficient in at least one theme: SVN or Git (Github is service on top of Git and it's irrelevant to task "repository migration")
Another way is:
read and understand git-svn topic from Git Book
convert SVN-repository to local Git-repo
using fresh Git, discover and use find-rev subcommand in git-svn for your task:
When given an SVN revision number of the form rN, returns the
corresponding Git commit hash (this can optionally be followed by a
tree-ish to specify which branch should be searched). When given a
tree-ish, returns the corresponding SVN revision number.
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.
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,
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.
As per the EGit User Guide, to use the merge tool, one should right-click on the resource with a merge conflict and then select Team > Merge Tool. However, when I do this, the Merge Tool option is greyed out. EGit is properly detecting the conflict and showing me both the icon and text label decorations for the file in conflict.
Any ideas?
It was disabled for me because I had some changes on my stash list.
$ git stash clear
fixed the problem for me.
It can depend on the version of EGit you are using, and on the operation that lead to the conflict.
See for instance bug 339092 which mention merge tool being not enabled in the case of a conflict after cherry-picking: only the just released EGit 0.12 would support that.
The only time (other than a bug) that the Merge Tool would be disabled is that when you are in any status other than the Conflicts one; i.e. you will only see that option enabled when the status is Conflicts. The status is shown next to the project name in most views, such as Project Explorer and Synchronize.
Make sure you have merged with desired branch, then if your merge results in conflicts, your project will enter Conflicts mode, and the Merge Tool will be enabled.
It seems to be a bug in EGit as VonC mentioned, but the fix is easy. I did it using reset branch option on the same menu that Cherry Pick option existed.
Note: git stash clear didn't help.
This happens if you tried to push changes to a remote and there were merges required from the remote. It fails with 'not FF' but also simultaneously detects the conflict. Don't ask me why it doesn't mark the whole project as conflicted at this point.
Open the Synchronize tab, right-click the project and select 'merge'. This immediately fails because of the conflicting file, and it switches on the conflict icon label for the project and enables the 'merge tool' option.
This is for EGit 4.0.3 in Eclipse Mars.
This also happens if you're in detached head state (in my case, I had checked out a remote branch and then forgotten).
Also, even after you've corrected the problem, you may have to select a different project and then reselect the one you actually want (just selecting in the package explorer view) in order for the menu to update.