I have a number of files in our depot that have filetype binary. I want to change them to binary+S, so only the latest revision is stored. The only way I can see to do this involves using p4 edit or p4 reopen, which means syncing down the file and checking it out. Then to commit the change, I have to submit the file, too.
This wouldn't be a big deal, but there are hundreds of these files, and they are a gigabyte each, and it's taking perforce forever (hours) to get them submitted.
Is there any way to do this, using the command-line or an API, that doesn't involve syncing down and submitting the unchanged large binary files?
Use the p4 retype command to change the type of existing revisions.
C:\Perforce\test>p4 help retype
retype -- Change rev type or archive (storage) type (unsupported)
p4 retype [-l -n] -t filetype file[revRange]
Retype changes the filetype of each revision of the named files
to the new specified filetype. 'filetype' may be a full or partial
filetype. See 'p4 help filetypes'.
...
'p4 retype' does not purge older revisions when a filetype is
retyped to a '+Sn' type. Subsequent edits cause revisions to be
purged.
After changing the type of a file, any client workspaces which
currently have this file should be refreshed by issuing
'p4 sync file#none' followed by 'p4 sync file', to ensure that the
client copy of the file reflects the new filetype.
Note the caveats around the +S filetype (old revisions aren't retroactively purged) and needing to do a special re-sync of workspaces that already have the file (you can cheat this with sync -k to avoid transferring the file). If you skip the re-syncing step, a workspace that had the "old" filetype and opens that file for edit will default to the old type (since that type is in the have record for that client file).
Related
Right before committing a major change, I accidentally "recovered" the file from an old and outdated swap file in vim. My changes seem to be gone. I've tried exploring the undo tree but large chunks of changes are still missing. Is there anyway I can undo the recover operation or am I doomed?
The following works for me to recover the file, with undo history as well:
Assume you have my_file, that has some persistent undo history + unsaved changes in .my_file.swp
Open file with vim, and press r to get the recovery version
Save recovery version to temporary location e.g. :w /tmp/%
Close without saving (:q!). Open file again, and press d to delete swap file
Optional: compare /tmp/my_file and my_file to make sure you want the recovered version
Manually add changes from /tmp/my_file (e.g. ggdG and :r /tmp/% )
This can probably be simplified, but this works for me.
PS: This does not give you the undo history for the changes between the on-disk and recovered version of the file, that appears as one big edit in the history.
After accidentally recovering the file you can simply type :q! to exit vim without saving the recovered changes - this will leave your original file intact and the swap file where it is.
The next time you open the file, you'll see the same prompt - press D to delete the swap file, or abort and find it manually (and possibly delete any other swap files in the same location)
I just tried this myself (with persistent undo enabled; Vim version 7.3.823). The old changes were still showing (in :undolist, though I usually use a plugin like Gundo or Undotree to visualize it), but when attempting to restore, I get
E438: u_undo: line numbers wrong
Seems like Vim cannot handle this situation. Note that you've been warned; the recovery explictly warns:
Recovery completed. You should check if everything is OK.
E308: Warning: Original file may have been changed
How can I restore a vim file from the undo file without hitting undo?
I had a vim file that I saved while adding text. Then I ran a python command that emptied the file's contents, and I can see some of the words the file contained in the file's .un~ file. When I try to undo in the file, it says Already at latest change. I can't find the swap file in my swap files directory.
As the other answers have noted, you can't recover the whole file from vim's undo files, simply because vim seems to only keep diffs in the undo files, not the whole contents. (That makes a lot of sense, as it's space efficient.)
One thing you can try though, is to extract what's possible from your undo file:
$ strings <undo-file>
The output will not be pretty, but you could end up finding something that's valuable to you.
You can't. The undo information is linked to Vim's last knowledge of the file's contents; when they don't correspond any more, Vim cannot re-apply the changes. This is documented at :help undo-persistence:
Vim will detect if an undo file is no longer synchronized with the file it was
written for (with a hash of the file contents) and ignore it when the file was
changed after the undo file was written, to prevent corruption.
Best you can do is try to manually salvage recognizable bits in the undo file, e.g. with a hex editor, or Vim's binary mode.
It is not exactly possible, as the undo file only contains the text that was changed in a single change. If you at some point reloaded the file, the undofile should contain the complete buffer for that and starting from there one could theorectically recover the file (by going through the undo states).
I have written about this before at the vim_use mailinglist here and here (which even contains a patch, that let's you force reading in the undo-file)
You could try to patch vim and see if you can recover at least some data.
A reminder that if you have set in your .vimrc file
set backupdir=$HOME/tmp
You may have temp copies of the files that are readable and that can be renamed
I like that vim automatically saves backup files, but it is annoying when I use vim to edit a file that is in a svn working copy, since the files are already "backed up", and it creates clutter.
How do I configure vim to only save backups when I am editing a file that is NOT in a svn working copy?
Not an answer to your specific question, but I believe a better solution. Why not backup all your files into a separate directory, regardless of whether they are in source control?
Here's how, from my .vimrc. This creates the backups in the common ~/.vim_backups directory:
" Use a common directory for backups and swp files
" Create it if it doesn't exist
silent execute '!mkdir -p ~/.vim_backups'
set backupdir=~/.vim_backups//
set directory=~/.vim_backups//
See backupdir option in vim (type :help backupdir) to create backup files in different location. You can put the definition of "backupdir" to your ~/.bashrc.
One additional point - you may still want backup files even if the file is controlled by svn, since backup will contain your local changes (not checked ones)
After I commit a file to Perforce with vi, it will become read-only.
If I have this file open in vim, then when it becomes readonline I lose my undo-redo history, without even being asked.
Is there an option in VI to preserve the undo-redo history when the file becomes read only while you are editing?
It is a Vim bug. Whenever you :edit filename, implicitly or explicitly it seams that Vim is zeroing all undo history for this file because ( I guess ) it think that it is newly opened file. And after perforce commit, your file is kind of “changed outside” and Vim should ask you “Reload file?” unless you set “autoread”.
Check you vimrc for “set autoread” option.
Maybe you could try to make it readable with modelines :
#vim : set noreadonly:
I wrote # but of course you must replace it with the adequate symbol for a comment.
Perforce's filetype system includes the +S modified to denote that a file is a temporary file. The implication of this is that no file history is stored for that file - only the most recent version is maintained, and it is replaced with each new checkin.
This is obviously a dangerous flag to set accidentally, which we recently discovered. Is there a way to ensure that this is not used in the future?
You can write a pre-commit trigger that looks at the file list for this flag, rejecting the commit if this is the case.
See this chapter of the Perforce manual for details.