I opened a file (p4 edit) and made few changes to it. I deleted (rm -rf) the directory which contained this file followed by a p4 sync -f to bring back the depot files (in hopes of getting rid of a lot of untracked/generated files in the directory).
However, it helped me only partially. While I was able to get rid of of the undesired files, the sync step could not bring back the edited file.
I can see that the file is in opened state with p4 opened, but I can't seem to find a way to bring back this opened file along with my changes.
Any clues?
Edited files are not stored on the server; they are only stored locally. Since you removed the modified file with rm -rf you cannot get it back (unless the file was backed up by another process, such as a netapp .snapshot directory).
The server keeps track of the state of files but the changes are not stored until you submit.
Related
I have
A git repository
A folder on this repository
To this folder I upload .SQL files. A new DDL is a new .SQL file and it is uploaded to the same folder as this is the place from which a CICD process kicks off to act upon this new file. I do change the sql code now and then but have no use for them after a certain point as it gets executed to the ultimate database via Liquibase
The Problem
Over time this folder now has close to 5000 .SQL files and growing everyday
Its getting cumbersome to navigate and find anything in this folder
The CICD build out of this folder is taking a lot of time it zips the entire folder
I want to
Archive/Remove everything more than 3 months old from the main folder
Move the old files to an Archived location so that I can refer to them
Get the file count down to a manageable level
Possibly do the archiving in a automated way without manual intervention
I Do not want to
Delete the files as I have to maintain a history
Change the process as may be have only one sql file and keep changing it.
I do not want Delete the files as I have to maintain a history
And yet, this is the simplest solution, as you still list the history of a deleted file.
# filter the deleted file to find one:
git log --diff-filter=D --summary | grep pattern_to_search
# Find the log of a deleted file:
git log --all -- FILEPATH
That means your process would simply:
list all files older than a certain date
add their name to a "catalog" file (in order to query them easily later on)
delete (git rm) them (their history is still there
For any file present in the "catalog" file, you still can check their log with:
git log -- a/deleted/file
I am new to perforce, i submittet my previous project to it as asked and added the p4ignore later. but now i dont want the files from the p4ignore like the .vscode folder on the server however when i try to mark for delete it also deletes them from my machine. how can i remove them on my server but keep them on the local machines
You probably want to use the p4 obliterate command; this is used to permanently remove files from the server (including all their history), which will leave your local files in an untracked state. Note that this requires admin level permission since file history is normally considered immutable.
If you can't get an admin to help with this, you can use the p4 delete -k command to open the files for delete while keeping the local files. This is a little tricky because it still results in a deleted revision, and if you're not careful you might end up getting surprised at some point by having a sync operation delete your local files (e.g. a force sync may delete your local files to force them into agreement with the head depot revision even though they aren't on the client have list).
To avoid that potential problem, after you delete the files, exclude them from your client view. That will not only prevent them from being added (similar to .p4ignore) but will also firmly exclude them from any operation that touches client files, including sync. (I usually recommend using the client view to exclude files in the first place instead of p4ignore -- it has the advantage of being tracked on the server, and it also prevents you from syncing down "ignored" files submitted by other workspaces whose settings don't match yours.)
tl;dr: use obliterate for mistakenly added files if you can, otherwise use a combination of delete -k and client view tuning to make sure the depot and client files are hidden from each other.
I wanted to unstage files (as my .gitignore was not set up to ignore some of my IDE files) but in hurry did :
git add w3
//got some .settings etc folder and files added, in newly added sub folder w3
//the repo here already had sub folders w1 & w2.
Then issued:
git rm -f w3/*
I'm on windows 8. The files are hard deleted (not in the recycle bin). Any thing I can do with git or any other (free) way?
Edit Add
* Also it was opened in STS(eclipse) but now deleted the pom, settings everything. Anyway to restore from within eclipse?
Un-commited but added files are still in a repository for a while, however it would be quite tricky to restore it especially for a large old repository as usually it has a lot of garbage. So, if you don't mind dig into garbage, start with git fsck and look for dangling blob.
However, seems you cannot restore names of lost files, only content.
If the file was not versioned you can't restore it. See the documentation of git-rm. See here for how to undo adding a file to the staging area.
If the file was versioned you can retrieve it from a past commit. See this answer for more information.
Of course if you back up your drive you might be able to restore it with your back up program. For that you might get help over at SuperUser.
What I did:
renamed a file
tried to commit
cvs fails with error message
file should be removed and is still there (or back again)
What is the problem and how do I solve it so that I can commit?
Additional information:
I'm using Eclipse with the CVS plugin.
doing an ls in the directory where the file was shows that it is not there
All the other Google hits for this problem (including this question) seem to be asking what to do when a file has been removed with cvs, and then restored outside of cvs' scope. My problem is different: I just need to rename a file.
It means that the file was flagged for deletion by CVS but then appeared again. Renaming for CVS is just a deletion of the file with old name and adding the file with new name. The file must be appeared again with its old name.
You can do 2 things:
1) If you don't need this file then just delete it. (Use cvs -n update command to find its name.) Then you will be able to commit.
1) if you need this file to stay, go to the .CVS subfolder of the folder where the file is located and edit Entries file. Find a line with your file and delete it. Then rename you file (give it a temporary name), call cvs update, rename your file back overriding the new one appeared after cvs update.
On the project I'm currently working on, we have lots of folders in the /branches and /tags folders (left after the migration from Subversion to Perforce).
I want to clean up the mess - I want to move/copy/rename folders remotely, directly on the depot, without getting them locally. I can't get them locally because we're talking about hundreds of GB and probably millions of files - dozens of branches x ~5GB.
Is it possible to order Perforce to move the folders just on the server?
(I do not have direct access to the Perforce machine, I cannot move folders around on the server or update the Perforce database).
p4 copy -v allows you to copy files in the depot without syncing those files to your workspace. (See the copy reference for more details.)
p4 delete -v allows you to delete files in the depot that are not synced to your workspace. (See the delete reference or KB Article #1148 for more details.)
Also p4 move -k allows you to move files in the depot without moving them locally, but I'm not sure if that applies if you don't have them synced to your workspace. (See the move reference for more details.)
You can also accomplish a move with a copy followed by a delete.
I think that you can construct a workspace that maps all the files in question. You can run sync -k to make Perforce think you have the files locally. Then you can run move -k to move the files on the server.
Just FYI, p4 copy creates a new branch, whereas p4 move moves an existing branch to a new location.