In Textmate 2, when you rename a file, the new filename shows up in the file-browser sidebar, but the old filename does, too, with a red X. The old filename won't go away until you commit your name change. This has been infuriating me for years. I refactor & rename a lot, and I constantly click on the wrong/deleted filenames during the refactor.
Is there a way to disable this behavior?
I have tried disabling all SCM-related bundles, but that doesn't do the trick.
This is new last week:
It is possible to set excludeSCMDeleted = true in a .tm_properties file to hide the “ghost” items that appear after deleting a file on disk which is still tracked by your version control system.
Related
I have a long standing issue with P4Merge. When I diff a workspace file with the version in the depot and then proceed to edit the workspace file, within P4Merge, after every edit and save the cursor jumps back to the top of the file. This force me to navigate back to the last diff I was at.
So the steps are something like:
Diff workspace file with depot version
Edit workspace file by pressing Edit File (in right pane) button
Edit the workspace file
Save the file (ctrl+s)
The result after step 4 is that you are automatically scrolled back to the first change in the file and have to track back the change you were previously focused on.
Is there any way to prevent this from happening? I.e. I just want to stay at the current line and be able to proceed to go to the next or previous change from there.
No, there is not a way to prevent this -- sounds like a bug more than anything.
As a workaround you can configure other merge tools to use with Perforce. Since you're on Windows my personal recommendation would be P4WinMerge (the merge tool that used to be bundled with P4Win -- I always found it a lot less "jittery" than the newer one so I never bothered to switch over), which you can still download thanks to the Wayback Machine:
http://web.archive.org/web/20160703111618/http://filehost.perforce.com/perforce/r07.2/bin.ntx86/p4winst.exe
I have problem in working with link command in linux mint.
I made file1 and add a new hard link to that file :
link file1 file2
I know when I change the contents of file1 , file2 should change too.
and when I edit file1 with vim or add text to it with redirections it works well but when
I edit file1 with kate editor then it's like that the editor break the link of file2! and after that when
I change the contents of file1 with kate or vim,... file 2 will never change any more.
what's the problem?
I'm one of the Kate developers. The issue is as follows: Whenever Kate saves, it does so by saving into a temporary file in the same folder, and on success just does a move to the desired location.
This move operation is exactly what destroys your hard link: first, the hard link is removed, then the temporary file is renamed.
While this avoids data loss, it also has its own problems as you experience. We are tracking this bug here:
https://bugs.kde.org/show_bug.cgi?id=358457 - QSaveFile: Kate removes a hard link to file when opening a file with several hard links
And in addition, QSaveFile also has two further issues, tracked here:
https://bugs.kde.org/show_bug.cgi?id=333577 - QSaveFile: kate changes file owner
https://bugs.kde.org/show_bug.cgi?id=354405 - QSaveFile: Files are unlinked upon save
The solution would be to just directly write in all these corner cases, then we could avoid this trouble at the expense of loosing data in case of a system crash, so it's a tradeoff. To fix this, we need to patch Qt, which noone did so far.
Different programs save files in different ways. At least two come to mind:
open existing file and overwrite its content
create temporary file, write new content there, then somehow replace original file with new one (remove old file and rename new one; or rename old file, rename new file, then remove old file; or use system function to swap files content (in fact, swap names of files), then remove old file; or ...)
Judging from its current source code, Kate is using the latter approach (using QSaveFile in the end, with direct write fallback though). Why? Usually, to make file saving more or less atomic, and also to make sure that saving won't result in errors caused by e.g. lack of free space (although this also means that it uses the space of sum of old and new file sizes when saving).
I don't have Kate on Linux Mint but I have noticed issues which lead me to suspect you may have come across a "bug".
Here are two 'similar' issues with hard links that have been reported.
Bug 316240 - KSaveFile: Kate/kwrite makes a copy of a file while editing a hard link
"Hard link not supported" with NTFS on Linux #3241
Let's say I've branched a file in perforce and edited it. Now I'd like to discard the branch history and treat the file as a fresh add. What command accomplishes this?
This scenario arises often because my IDE insists on treating a copy as a branch/edit. After making extensive changes to the copied file, it causes confusion to treat it as a branch/edit.
You can revert the new file and then add it back, without the copy/move.
cp /path/to/new/file /path/to/new/file.bak
g4 revert /path/to/new/file
mv /path/to/new/file.bak /path/to/new/file
g4 add /path/to/new/file
But, the history is there for a reason. If one exists, you might want to keep it - it might be helpful to see the lineage (even if muddled) at some point in the distant future. Consider changing your settings on your IDE.
In your IDE:
Create a new file with the new name
Open the old file
Select the contents of the old file
Copy to the clipboard
Open the new file
Delete all the contents from the new file
Paste in the contents of the old file.
Then the IDE will do a new in perforce instead of a branch, the above is only a few keybaord presses if you use your IDE keybaord shortcuts.
Using P4V 2009.2.
I have used P4Win in the past, but this is a new setup for me.
The problem is that the files I have checked out disappear from the changelists, so I cannot check them in.
To reproduce:
Check out a file, make a change to it.
Go to the 'pending changelist' tab.
There will be a + sign on the default changelist.
Click on the plus, or on the changelist line, the plus will disappear, there will be nothing in the changelist.
Try to check the file in by right-click on the file itself, the changelist dialog will show up but NO files are listed.
You can transfer the file to a new changelist, the same thing happens.
Looking at the file in the 'checked out by' window does correctly show the changelist number & description.
It sometimes happens to me, and what I normally do is change workspace and then change back again. Not sure if there is an easier way to get it to realise the files are checked out.
the only thing I can imagine is that you are looking at a different client workspace. Notice that the "Pending Changes" tab has a filter on the top, where you can separately filter for folder/files, user and workspace. Maybe the filter is set to something so that it doesn't match the client workspace where you have actually checked out the file.
Good luck,
Henrik
You may get this if the perforce server has not been upgraded. Old versions of P4D have this error: http://kb.perforce.com/article/1167/opened-files-missing-in-default-changelist
If that is not an option, use p4Win.
I agree with jhwist,sounds like your looking at a different client spec.
P4V is a bit confusing on this front, IMO and I personally prefer P4 Win but to check, open up a command prompt and type p4 changes -s pending -c YOURCLIENTSPEC - chances are that the changes you think you have aren't in your current clientspec
This can happen sometimes and in my experience it is a refresh issue with p4v. Often simply closing the pending tab or reopening p4v solves the problem.
In my case, the pending List has over 4000 files, (due to eclipse created so many files after mvn tasks) so none of them are shown. I created a different pending list, then cleared all contents, then moved the files to the new change list. Then it is appearing in the new change list.
Modify the file directly in the correctly mapped client folder (i.e. your current workspace). You will see the changelist for sure. As jhwist mentioned clear filters if any and choose your current workspace (since you may have many)
In the 2009.1 version of Perforce Visual Client for 32-bin Windows, the "Reconcile Offline Work" option does weird things. In the middle box where the "Local files not in depot" should be displayed, I never get anything. What I do see is that the first time I reconcile a folder, it looks like perforce is filling the box with the "local files not in depot" because a list flashes quickly before my eyes. Then all of a sudden, the list quickly disappears into thin air and I'm left with an empty list. Does anyone know how I can get this feature to show me the files that I have not yet added? It seems like the "Modified files" and "Depot files missing from workspace" features work fine.
Also, as a side note, "Reconcile Offline Work" seemed to work fine in the 2009 beta version.
I had exactly the same problem.
The solution for me was obscure but trivial.
I simply changed the root directory of my client workspace from "C:\depot" to "c:\depot".
Yes, that's right, all I did was to change the drive letter from uppercase to lowercase. And, yes, I verified that changing the drive letter back to uppercase breaks it again and that changing the drive letter back to lowercase again fixes it again. So, this is not just a coincidence.
This is almost certainly a bug in the Perforce reconcile feature.
If you look closely at the reconcile paths, they all appear with a lowercase drive letter, even if you specify an uppercase drive letter, so my guess is that the matching algorithm is simply doing a case-sensitive comparison on the file paths. This is appropriate for everything but the drive letter. Their file lister probably always sets the drive letter to lowercase, so an uppercase drive letter on your client workspace root will never match.
This certainly sometimes happens. I seems the problem is likely to occur if I change the workspace view somehow and/or upgrade P4V to new version. So the solution which worked for me in the past was to trash the problematic workspace and create a new one (sometimes have to choose a different name too).
Perhaps deleting the .p4qt and .p4scc in your user home directory can help too.
Incidently, I did have a conversation with Perforce support on the related subject some time ago, and as the problems like this are very difficult to reproduce, therefore there wasn't much that they could do.
I have found issues with long filenames in p4 reconcile
from the base direectory
p4 reconcile ./...
never returned.
but if I cd further up the tree
cd components
p4 reconcile ./...
worked.
I was able to reconcile the whole tree eventually by stepping up directories, depending on how much longer your paths are this might work for you.
I had an instance where p4v showed the visual indicator that files had changes, and doing a diff showed the changes appropriately, but resolve on any parent directory didn't show them.
Those files had been changed by downgrading a library using a unity package install, and their "last modified" date was older than the previously submitted files. On OSX running the touch command on all the files in relevant directories updated all their modified times and reconcile worked after that.