We recently have moved from SVN to GIT, and until recently, the problems with the move were if not minimal, at least manageable.
Until a few weeks ago, we just had a single active 'master' branch, which was the old SVN trunk. But then, we added a branch to do a major upgrade while keeping the master available for bugfixes that could then be easily deployed.
The problem is that as soon as the different project team members started to check stuff in, the Eclipse (Mars 2 with EGit) Team Synchronization perspective started showing stuff as needing to check in that really didnt.
The first time I synchronized, a load of incoming changes came in (the blue arrow) which was unusual as I hadn't seen any since moving to GIT, - we just had to do a PULL instead - so foolishly I accepted them in. That ended up merging the changes we had put in the trunk with the branch, which we DIDN'T want to do.
Worse, even after pulling in those changes, they still appeared but now as conflicts, even though I accepted them and the files were identical. Nothing I can do (Mark as Merged, Overwrite, Commit...) gets rid of them.
Anyway, the most unhelpful problem is that now the Team Synchronization brings in hundreds (currently 825!) supposed changed files when I do a synchronize now. Many of these files are obscure ones that havent changed in years, and are clearly unchanged yet they show up. Trying to sift through the file list to find what I have actually changed is too much effort, especially as Eclipse helpfully refreshes the list with all the items I removed from the view each time I make any change!
So basically now I am resorting to GitKraken, which has substandard diff tools but at least shows an accurate view of what needs checking in. Why they decided on the Duplo-sized fonts that take up so much window space in the staging area I have no idea. And it's SLOW.
I now have a healthy dislike for GIT because its such a faff compared to SVN, although I acknowledge a lot of this is down to the GIT implementation in eclipse.
So, does anyone have any tips about how to get Eclipse to recognize that most of these files shouldn't actually be displayed? Am I missing some configuration somewhere? When I right click on the project in eclipse and do Team > Switch To, it correctly shows the branch Im working on, so why is it so inaccurate? Im using Eclipse Mars2 4.5.2 with JGit 4.6.1
Any tips appreciated.
For anyone else having similar problems with this, I sort of have an answer.
My answer is, that Im not sure what got it working, but my team synchronizing perspective now shows 99% the correct view. I clicked on various things with increasing desperation to get this to work and then some combination of the below in the Team Synchronizing perspective had the right effect:
In the Synchronize tab, select the down arrow next to the view type and select either Java Workspace (for the master) or Git Commits (for the branch)
Click the down arrow next to the Synchronize icon at the far left, select Synchronize and then Git, then select the correct destination (eg ref/heads/master) and then clic on 'Include local uncommitted changes in comparison'
Hopefully thats of help to someone.
Related
I don't understand something that is happening on my Eclipse and I am wondering if this is my Eclipse problem or if this is actually a feature. I have a trunk and a branch. On the repository they are the same so no changes have been commited since I created the branch. After making the branch I switch on my workspace the project from trunk to branch. Then I started working and changing on the branch. Suddenly I wanted to see something on the trunk because I got lost in my changes. So I switch to the trunk. I was surprised when Eclipse did not remove my changes and it was as if no switch was made. The changes continued being there.
Is this normal?
Can someone explain?
Thanks,
David
This is perfectly normal, and the way the svn switch is suppose to work.
Here's a common scenario. You're working on trunk, and realize that your changes should be applied to a branch instead. You simply do switch and you are now on a new branch and your changes are now applied to the new branch. Many times, I'll be working on one stream (a branch or trunk), and realize that my changes are too experimental and big to go into the current development stream. I'll create a new branch and switch to it.
There is no reason with gigabyte fast disks, and gigabyte networks to be skimping on working directories. I tell developers to dedicate a working directory for each project and branch. Otherwise, if they keep switching back and forth between various development streams, they're going to forget and do development in the wrong place.
With almost any svn client you can:
check out a project
make some changes
switch back and forth to any truck/branch
preserve your changes along the way
In other words, nothing specific to eclipse here.
see: svn switch
I prefer to have separate eclipse projects per branch and also change the project name to something like myProject-24 so when the branch is checked out again down the road, the default project name has some branch identifier on it.
This also enables you to make changes on a per branch level and do single commits across the branches; even if they're in discreet eclipse projects.
The functionality you are looking for can be reached by doing the following
Right Click on the folder that should be replaced
Click on "Replace With ..." from the context menu
Click on "Branch ..."
Select the branch you want to take a look at from the dropdown box
ATTENTION: This is replacing your local changes. It is not possible to reverse this.
Greetings
Tobi
I think I am just merely (coming from an SVN background) confused with how Git conflicts are handled by EGit within Eclipse.
I understand that it shows textually in the normal standard method by which to show conflicts as stated here: http://www.kernel.org/pub/software/scm/git/docs/git-merge.html#_how_conflicts_are_presented however it isn't very clean and with thousands of lines of code it becomes unmanageable to avoid accidently deleting lines that are not meant to be deleted.
Is there any GUI within EGit that can show me each conflict with an step over ability?
I have searched around and I heard about the merge tool however when I follow the instructions by right clicking on the top level node of the tree (i.e. right click models folder that has the <> type icon denoting a conflict, which has a conflicted file of User.php within it) the merge tool is greyed out.
Am I using the merge tool wrong?
Edit
I found out that a bug can cause EGit merge tool to not show: Why is the merge tool disabled in Eclipse for a EGit-managed project? however I am using EGit 1.3.0 so I should be way past this bug.
I have given this question two days both here and on the EGit forums: http://www.eclipse.org/forums/index.php/t/371459/ unfortunately (even after everyone viewed it) no one had a real answer so I decided to solve my conflicts manually and just merge that way.
This way was, in reality, quicker and easier than trying to solve why the merge tools were not working for me, ironically.
I have been using TortoiseSVN for a while now and just recently started using the eclipse plugin subclipse. I am really happy with it, although there is some stuff confusing me.
I have a few projects, which each have a different subfolder in the repository. I never worked with branches (so far), so my SVN use was fairly easy.
Update to head
Solve conflict if there are any
Make some changes in the code/project
Commit (Tortoise tells me, if an update is neccessary before)
Now with subclipse, I fell that there are other possibilities. For instance, what's with the synchronize view? I don't really get it. At the moment, I use Team->Update to head/Commit on the project folder and if there are conflicts, I use Team->Edit conflicts... on the conflicted file. That's it. So I never touch the synchronize stuff. I haven't really found a good explanation on the subclise page or google...
Is the idea to just synchronize and everything is done automatically or what?
Basically, I am asking for the workflow (or some link to a good basic explanation). I am not asking, what is possible or what does what, but how subclipse is intended to be used for small projects (<100 files, <5 persons working on it, no branches so far).
I do not think there is any reason to use the Synchronize view if you do not want to. I really like just doing Team > Update and then resolve whatever conflicts occur. That is much more the "SVN-way" to do it. The Synchronize view comes from Eclipse world, so Subclipse had to support it.
TortoiseSVN does have an option that is kind of/sort of like the Synchronize view. It is the "Check for Modifications" option. Particularly when you press the "Check Repository" button.
Also, keep in mind that the Synchronize view does not show "conflicts" the same way as SVN. In SVN, a conflict means that it could not auto-merge the change in to your file. In the Synchronize view, it means you have local modifications to a file that has incoming changes. It is possible, perhaps even likely, that SVN could automatically merge those changes if you just did an update. Personally, I would rather just let SVN try to do it.
The synchronization view allows you to recognize conflicts before you perform an update. If you perform an update and you are getting conflicts this means that you have to stop what you were doing before and start solving the conflicts. This is an interruption of your work-flow.
Usually if you perform an update and get conflict(s) you loose the ability to run and debug your program. using the synchronization view you can update the conflicting files one-by one, which allows you to integrate the remote changes step-by-step into your project.
Therefore you can start solving the conflict without loosing the ability to run your program. Or you see that there are many conflicts and decide that it is not a good time to perform an update at this time.
Hence the synchronization feature is very powerful if it comes to detecting, preventing or solving conflicting changes in an SVN.
when i startup eclipse, first thing i usually do is updating my source code to pull in changes from other developers (or from my home work). Sometimes i just forget it. But as we are usually working in a small team on HEAD, we all usually want to have the latest sources.
It would be nice to let eclipse automatically (like every hour or so), synchronize its workspace with CVS server and mark the project with a label for pending updates (of course it shoul dnot update the source code automatically!)
I have searched the web for it and i found some comments on CVS watch/edit feature. But i don't like to call edit every time i work on a file and i don't want to be informed by mail. All i need is a little icon at my project which says "You might run cvs update before you work on".
Is something like this available as a feature in eclipse?
regards
Janning
Well, what you're asking for is precisely what the CVS watch/edit feature is for. I agree that the emailing issue is a major PiTA but hey - remember - CVS is quite old; many CVS concepts appear a bit odd nowadays, whereas they appeared more reasonable when CVS was first written.
I cannot think of any internal, Eclipse-provided way to do what you're asking. You basically need the "Synchronize" view to be updated periodically - and, the way that the CVS plugins are written - that view is only populated upon startup and whenever you select "synchronize with repository".
Isaac
I have a folder where I keep checked-out version from Aptana Subversive SVN plugin. I have another folder where the checked-out copy from Eclipse resides. Both, Aptana & Eclipse, are using the same repository. Though the repository is the same, but I am using two different working folders. Sometimes I use Eclipse to work with the same set of files in the repository and sometimes I use Aptana.
I want a tool that can synchronize the two working folders automatically. Is there any free tool?
Actually, SVN is the tool to do just that. If you fight SVN, you will run into trouble, because you might not have both working copies updated to the same the same revision, the merge tool messes up the hidden .svn folders and whatnot.
Why do you think you need to manually synchronize those two working copies? If you want to work on both simultaneously without disrupting other's work because you keep checking in half-baked things, consider working on a branch. Doing so, you make use of SVN, which was designed to keep two working copies in sync. If you're done with whatever you're doing, merge that branch into the trunk (or whatever branch you were working at) and throw it away.
If you feel like all this checking in might make your repository become too big, get a bigger disk to store it on. The very first time you or that tool messes up manual merging, it would have payed off. If you're afraid of bumping SVN's revision count without doing actual work, get a grip.
Araxis Merge has automated merge.