I am creating successfully a subtree to a remote repo and pull/push successfully using Sourcetree. The substree repo appears below "Stashes" tab on the left of Sourcetree as "Subtree" tab.
However, when I close and reopen the Sourcetree, the "Subtree" tab and the subtree that I have defined earlier, disappears.
It does not disappear, if I close the project tab and reopen the project without closing the Sourcetree.
I have seen these two post with the same/similar problem:
First Post
Second Post
Both links belong to the same person.
I have tried the suggested solution there (clearing cache) but it did not solve my problem.
The person, who was in charge of developing this part of the Sourcetree, has not posted since 2017. Maybe he left Atlassian, and this issue is still there.
I have already asked this question in the Sourcetree forum, but no replies since April.
I have opened a bug report at this link
I have tried version 3.3.9 and the problem is still there.
It seems to be a simple "save" issue. I also remember that Sourcetree did not have this issue in the earlier versions.
I found out that this is consequence of another major issue with Sourcetree versions came after 3.2.6. After this version, a major bug is introduced, probably something related to authentication, and it results a constant red exclamation mark on the remote button. This mark can be fixed in version 3.2.6, but not in the later versions. So, I am staying with version 3.2.6 for now.
Related
I've reinstalled my PC and tried connecting back up to my Azure DevOps Repo using VS Code and TFVC. I'm using TFVC Location with Visual Studio 2019 Community TF.exe. It all seems to work and I can connect to my repo with my credentials. It all seems to load up fine and I can even see TFVC with a number of changes/differences. - see image below. However I'm expecting to see my source control and list of files to commit like before. But the panel is blank. There's no errors in the Output window of VS Code either.
I've tried removing and re-adding the workspace. Tried editing/adding anew file to the project in hope of kickstarting TFVC pane to show the file list. - the number next to TFVC updates but I don't see any menu button or files list.
Has anyone else had this and know a solution, or know where I'm going wrong.
Just toggle "scm.alwaysShowProviders" on and off from whatever value your have (default is false), this would cause the source control pane to redraw and fix the issue for now.
I believe per the issues in GitHub that this issue is fixed for most people as of VSCode version 1.39.2, but I was still seeing it for projects based on a Git repo.
After some trial and error I found this setting was the culprit: "scm.alwaysShowProviders": true
When I remove that setting, or set it to false, my Source Control pane works correctly.
This happens to me occasionally. I just figured out I can fix this by right clicking in the blank area and then selecting the repository I want to show up
Issue opened on GitHub: https://github.com/microsoft/vscode/issues/82374
For now I've rolled back to the August update and that's resolved it.
Clicking the blank area and slecting repo does the trick
I had this problem on the 1.55 version, as it's centrally controlled I couldn't manually update, but when they pushed the 1.64 version through, the problem has gone away, was driving me mad!
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.
Recently I switched from Eclipse Kepler to Eclipse Luna.
In Kepler when I opened Team > Switch To... I only saw open/ active branches.
Now in Luna when I open this dialog I see ALL branches that were ever created in this repository. And that is a lot :(
Also, when I switch to our "default"-branch it says "24 heads" because two years ago there was an incident and someone created that many heads for this branch. The heads are long closed, but my Eclipse-Mercurial-plugin doesn't care. I still thinks that those heads exist, because it ignores the "closed" status of the branches.
I already checked the Preferences and I found no possibility to change the setting for that. Besides, the settings are identical to my Kepler-installation. Also, I have the same Mercurial-plugin ("MercurialEclipse project", 2.1.0.201304290948, com.vectrace.MercurialEclipse) installed in Kepler and Luna.
(my OS is Xubuntu 14.10)
Can anyone help?
Hm, there wasn't really a solution for this :) But I want at least to describe what happened.
I was the only one in our team who had that problem. We found out, that when we use our existing workspaces we had no problems. When we did a completely new check-out into a fresh workspace from our Mercurial-server, we had all the problem described above. (That's the reason I was the only one with the problem: When switching the Eclipse-versions I also decided to start a fresh workspace) So we dug further and found out that all branches we had once marked as "closed" had lost this marker. So that's why they all appeared when I opened the switch-to-dialog: the dialog showed correctly all non-closed branches.
We don't know how this could have happened. No one opened all branches on purpose. Perhaps a Mercurial-bug? And the fact that it didn't affect existing check-out made it even more strange.
The short-term solution: I copied an existing workspace from a colleague and happily continued programming.
But we knew that it would be a problem for anyone who would join our project in future.
So we just switched to git :)
We were already discussing this for months, like: should we switch? shouldn't we switch? weighting pros and cons. So this bug seemed to be the perfect reason and opportunity to do the switch.
conclusion:
It wasn't an Eclipse-bug, but a Mercurial-bug. And the solution was git :D
I have been using EGit to upload my stuff to github for a few months now.
But off late I do not see what files have been changed, and I dont know why. Please help.
As you can see I have updated some files and I cannot see a list of files in the files section.
This looks like a problem with Mac OS X 10.10 and SWT, see Eclipse bug 446534 for details.
Note that the heading above the table says "Files (1/1)", so EGit calculated the changed files correctly, but it isn't visible. Try if resizing the window makes it appear.
The Git Staging view, which is another way to commit using EGit doesn't seem to have the same problem. Maybe you could consider using that instead of the Commit dialog, see the user guide.
As the comment 2 at the Eclipse bug 446534 mentioned, calling table.pack() will solve this problem for a single tableviewer.
We are using ClearCase using a single Dev stream for our team, without 'locking' (Unreserved check outs).
ClearCase client version: 7.1.1
ClearCase server version: 7.0.1.2
We have performed the same test, without using the "Graphic merge". This option worked as expected! Maybe this can shed some light on past defects on ClearCase or workarounds.
This means that 2 or more people can make edits to the same file at once, without having to wait for for the file to be checked in.
We have seen a few cases of weird behaviour and experimented a bit today to find the following scenario that takes place:
File.txt is checked out by 2 team members.
Each members makes a change in the file (in other regions of the file).
First developer checks in the code to ClearCase, no problems here.
Second developer checks in, gets a merge popup notification.
When selecting "graphic merge", ClearCase in this case informs that all merges were done automatically and no additional input is needed from the developer.
Looking a little further, the first check in was removed (deleted), keeping only the later check in changes.
Why is this happening? This is causing our team to lose code on several occasions already. Are we doing something unsafe/wrong ?
Edit: Illustrating the problem with images of the issue:
The file Manager.cs is at version 27.
Two developers are checking it out.
One made a change, checked in.
The other checks in, gets the merge notification.
This is what i see in the graphical merge:
Note that on the left is version 27, in the middle version 28 (the latest checked in version), and on the right is the result which is dropping version 28's code change !
Why is this happening automatically??
Image can also be seen here: Image
Note: if you are using ClearCase without 'locking', that means you are doing unreserved checkouts (and not reserved checkout).
If you select "graphic merge", you should see a Windows helping you to reconcile the merge, even if there is no conflict.
Such a merge should not delete any previous checkins: it might cancel the previous modifications, only if all the new changes are selected, but if you have the graphical merge window open, you can control how the merge is applied.
For your past problematic merges, you can easily from the version tree re-apply the merge from the previous version of dev1 to the LATEST version, in order to reapply those canceled changes.
Since my initial answer 4 days ago, 2 new information came about:
ClearCase client version: 7.1.1 ClearCase server version: 7.0.1.2.
That is never good to have a client with a version more recent than the server.
We have performed the same test, without using the "Graphic merge". This option worked as expected!
That would be consistent with some discrepancies already seen between the GUI for merging and the pure command line (as in this other scenario).
When the GUI fails, always try to fall back on the pure CLI (Command Line Interface).