Perforce Integrate command to remove local files/directories which are not present in repository - perforce

I am looking for a perforce integrate/get-latest command which would fetch the latest/updated-code and remove the files/folders that have been moved/deleted from the perforce(server) repository.
Is there any way by which I can get a clean copy of the perforce repository, without creating a new workspace/local directory?
Thanks for your interest.

What you're looking for is the sync command. It will grab the latest files, and it will remove any files that were deleted. I'm pretty sure it won't remove the directories, though, at least not on Windows.
To get a clean copy, you can delete the local files, and sync using the '-f' flag.

As of release 2014.1, you can get a clean copy of the repository by using "p4 sync" and "p4 clean". The "p4 sync" command will fetch the latest versions of files from the repository; the "p4 clean" command will remove/refresh anything in your workspace that was not put there by a sync:
http://www.perforce.com/blog/140501/p4-clean-make-workspace-shine
Setting the "rmdir" option in your client spec will tell "sync" and "clean" to remove empty directories as they are emptied by those commands:
http://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_client.html#d0e7978

Related

How to go back to the Working Directory that was not committed

I forgot to commit on the directory where I was working and then I checkout to the previous commit and now I want to back to the directory where I used to work. What can i do ?
If your checkout of the previous version somehow deleted your folder, which was not added/committed, then you would need to rely on a file recovery utility, as detailed in "Can I restore deleted files (undo a git clean -fdx)?", or on your IDE. Some of them keep a local history (IntelliJ IDEA, VSCode through an extension, ...): you might get back some of your files content that way.
In the end, it depends on the exact git checkout command you did, considering this command can update files and/or branches.
That is why it is recommanded to use git switch (branch only) or git restore (files only), instead of git checkout.

How to detach a folder from being tracked without deleting any files from it?

I completed MyProject1 and have uploaded it in git in fine way with commits after adding each new features. And now I'm starting MyProject2 and was trying to add the URL for the remote repository. But then I found out that I had mistakenly added the URL in Documents instead of MyProject1 folder because of which MyProject2 folder is also being tracked in MyProject1. And I'm not being able to add URL to MyProject2 but instead facing merge issues.
Is there any way to detach the track from my Document folder without deleting any of my files from Documents.
Structure is this way(I'm using Linux):
Documents
(And inside Documents there is:)
MyProject1
MyProject2
And other folders which are also being tracked.
We can manually do it with below steps
create a file .gitignore in base directory.
If MyProject1 and MyProject2 are already part of git tracking, Please run commands
git rm -r --cached MyProject1/
git rm -r --cached MyProject2/
Open the file in text editor and add below lines in file
MyProject1/
MyProject2/
Best way:
Create a .gitignore file following #Vinayagam R
Ignore file locally
Those methods won't affect other contributors working on the same remote repository:
Use update-index:
If you want to stop tracking a file at certian point.
git update-index --assume-unchanged yourDirectoryName
--assume-unchanged is the flag which means the files should not change locally. In other words, it is used when ignore files that you do not need to change locally (or should not change).
To revert it use update-index --no-assume-unchanged yourDirectoryName
Using .exclude
In your working directory edit .git/info/exclude

How to delete the old Perforce Workspace without damaging the work I've done on the exact same files under a new Workspace?

Trusty computer crashed and died while files were checked out under a Perforce Workspace. The New computer was not recognized by the old Workspace so I couldn't check the files back in. Had to keep working so I created a new Workspace to edit the exact same files.
I couldn't remove the old Workspace without reverting the files. But I don't want to risk copying over the work I've done on the exact same files under the new Workspace.
Is "p4 revert -k" what I want to do?
Suggestions? Thanks.
What you're really asking is how you can revert files in an old workspace/client that you can no longer access (because it's tied to a host that no longer exists).
The simplest way would be to ask your Perforce administrator to delete your old workspace. Someone with administrative access to your Perforce server can do p4 revert -C OLD_CLIENT to revert files belonging to another user and client, or the administrator can do p4 client -df OLD_CLIENT to delete the client outright.
If you want to do it yourself instead (note: I don't have a Perforce installation handy right now, so this is untested), then you could try:
Run p4 client OLD_CLIENT, clear the Host: field. Save and exit. This should allow further edits from a different host.
Run p4 client OLD_CLIENT again. Change Root: to point to some empty directory. Save and exit.
cd to the directory from step 2. Run p4 -c OLD_CLIENT revert ....

Perforce - marking local file as latest revision

I've got a following problem:
There are many huge files(gigabytes) on repository, they are not yet in my workspace, but I already have them on my local disk from other source(the same copy as the latest revision).
Is there any possibility to move these local files to appropriate subdirectory of my workspace and mark them on P4 server, that they are the same as latest revision, so I don't have to download them again?
Thanks in advance
The p4 flush command should do the trick here. In this situation, you would copy the files to the appropriate location in your workspace, then run:
p4 flush //path/to/file.ext#head
You can do an entire folder using:
p4 flush //path/to/folder/...#changelist

svn Merge Problem (3 levels of svn)

I am new to use svn and the company in which I work uses three levels (I don't know whether this is a correct word to use here) of svn. I mean the developers are provided a working directory on a testing server. When we commit, it goes to the dev server. When a manager commits it from there it goes to production server. I am a developer here and one of my files is giving error (conflict) when I commit from directory. Not only, but also it gives conflict when manager tries to commit. I am now given access as manager too but I am still unable to resolve it.
What I've tried till now:
svn update
svn delete
svn commit
It gives conflict on all of these operations.
Earlier on a simple error happened and the manager preferred to just delete file on dev, copy it manually and then commit from there. I don't know this may be a reason of this problem or not.
Please help me resolve this issue. I've read some things in read-bean book too but to no avail yet.
Thanks
Ok, here's the update. The actual problem is that a file (ex lib/a.php) used to be in my working directory as well as in dev and production servers. Now it was deleted by someone (using del command, not svn delete) from dev server. Now question here is how I add it again so that it becomes part of svn again. The simple svn add doesn't work.
Update 2
From one of the answers below I understood that its a tree conflict. Some searching brought me to http://svnbook.red-bean.com/nightly/en/svn.tour.treeconflicts.html . Following the instructions, I took the backup of the file and then svn delete it from everywhere. Then I svn add it to my directory, commit it and tried to update dev and production. End result is that it doesn't go there. No error is shown either.
svn info in my directory shows complete info of the file but on dev and production it shows
file_name: (Not a versioned resource)
:S
Any more ideas please?
Alternatively you can take backup of the file ,then say svn revert filename insert you new code.Do a svn up just to make sure you do not have any conflicts,and then commit
Or
fix the conflicts in the file and then you can say svn resolved filename and then you can continue operations on the file
Update:If your file is deleted using rm or del command use svn revert filename to get it back and you do not have to add it again.Just put in your new changes and say svn ci -m"your comments" filename
svn revert will fetch back the last checked in copy into SVN and it wouldnt have your any changes made before the user had used del command
Update 2:After u say svn delete ,u need to commit it until u get the message Deleting filename with a new revision number.Then add the file using svn add command,then commit again.Once this is done you can check the svn info, let me know..
Use svn status command to know the status of the file
The only problem apart from this i can think of is this the directory may not have been added.Is this a new directory?
ah, the old tree conflict problem.
The issue is that SVN is letting you know that you're adding a file that used to be there but it cannot tell whether you're trying to delete it, add it or just update it! So it does the only thing it can - flags a conflict so you can sort it out and fix it. Its basically a conflict on the directory level (rather than a conflict of a file's contents).
What you do is resolve the error (as others have pointed out), then update the directory to get the original file back, then commit your changes. Note that the file was never deleted from SVN - its still in the repo, and if you checkout out a new WC, you'd get the file.
Try to resolve the conflicts then commit again:
svn resolve --accept working

Resources