On my system, I have two hard drives; C and D. TFS 2010 installed on C and my TFS workspace installed on D to the Workspaces folder.
Drive D: failed and I had pending changes in the workspace that I do not wish to lose.
Since my C drive is okay, it is possible to recreate the workspace with all the pending changes?
Workspaces only keep a record that a file has changed, it does not record what those changes are. So you won't be able to get the Pending Changes from the other drive unless you created a Shelveset as a backup.
Related
I have synced files around 1 Tb from one server to another and set up P4, but I have a different workspace in the new server so if i initiate a p4 sync in new server, Will it add only the difference or will it duplicate the files?(source remains the same)
If the workspace map is the same as the old client, and there have been no changes, you can do a p4 sync -k. This updates the metadata on the server, without doing the file transfers. If there have been changes, you'll have to force sync those files to get the correct revision.
Since you created a new workspace, and P4 doesn't know that you have the files already existing on your new environment, it will pull over all of those files.
If you kept the same workspace name, (by default) it would pull over only "new" files (because it thinks you already have the files you previously synced).
I have a Unity project called, lets say, testGame in my Depot. On my C:\ drive, I have the Depot sync'ed so that Depot/Workspace are the same.
However, for some reason, the local copy of testGame in the Workspace has become corrupted- Unity is missing file references, errors are stacking up. I do not have this issue on other machines where the D/W are sync'ed, this is strictly an issue local to this machine.
Revert/Rollback has not fixed this. What I'd like to do is just nuke the local Workspace copy and re-sync from the Depot. Obviously, 'Mark for Delete' is not what I want. I tried "Remove from Workspace", but it just says "c:\Perforce_IntV2\prod\dl\testGame... file(s) not opened on this client"
Just using explorer to delete this files will also cause headaches- How can I just nuke my Workspace copy from orbit?
You can sync to version 0 (the 'version' of the files before it was there, meaning it will get removed) with you client of choice ('get revision...' in p4v, then tell it to sync revision 0; p4 sync //...#0 in the command line). You can do this on the root of your workspace, so everything that perforce knows about will be gone. Then delete in explorer whatever is left (verify that it's not some new file you forgot to add first though!)
If you really want to just nuke it all, deleting from explorer first will speed up the sync to revision 0.
Another way to nuke everything is to delete the files with explorer and delete the p4 workspace in your perforce client. You will have then to set up the workspace again though.
After any of those, just sync again and you're back to a clean workspace.
From P4V you can use "Reconcile" to figure out which files are off and put them into a changelist; once they're opened in a changelist, "revert" will put them back into the state that matches the depot.
From the command line, just run:
p4 clean
to clean up your workspace and make sure it's consistent with the depot (discarding any local changes that aren't already in a pending changelist).
I have an unusual situation. On TFS 2013 build environment, shelveset builds fail when the users shelveset contains added/new files.
The user creates a shelveset with the news files added and some
changes to existing files.
User queues a build with the shelveset.
The build server creates a new workspace, merges the shelveset files
and the added/new files all have "Warning: There are other pending
changes against the item." in the build log.
How do I fix this?
We ran into this a lot when we were in TFS 2013. They seem to have fixed the issue in 2015 which doesn't help you now.
I seem to recall that we could work around the issue by shelving without preserving changes in the local workspace so that there aren't conflicting pending changes from TFS's point of view. You could restore the files to the local workspace by unshelving them after the build completes.
Why can the same account not checkout files in the same branch but in different Workspaces?
TFS2010 and also TFS2013.
I have a number of Build Definitions and when I build one after the other I get an error when attempting to checkout all files in a directory with
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\tf.exe" checkout /lock:none /recursive /noprompt C:\Builds\75159\Scrum2012\2013_Developer\src\Testing\Internal
Here's the error:
Unable to perform operation on $/Scrum2012/src/Testing/Internal/Bin/Base.dll. The item $/Scrum2012/src/Testing/Internal/Bin/Base.dll is locked in workspace 10_75159_build2013;Account Service (ourtfs).
These files may already have been checked out with another Build Definition but by the same user on the same machine, so I do not understand what the issue is.
If I just stick to building with the same Build Definition it works just fine.
Why can the same account not checkout files in the same branch but in different Workspaces?
TFS reports 3 Workspaces on the same machine all with the same Account:
Workspace Owner Computer Comment
10_75159_build2013 Account Service (ourtfs) BUILD2013 Workspace Created by T
4_75159_build2013 Account Service (ourtfs) BUILD2013 Workspace Created by T
BUILD2013_5_75159 Account Service (ourtfs) BUILD2013 Workspace created by T
For server workspaces, if you are able to check out a given file multiple times depends on the "multiple checkout" settings; https://msdn.microsoft.com/en-us/library/ms252452(v=vs.100).aspx.
Since dll's don't merge that well, the default is disabled. But if you want you can change that for your filetypes to allow this.
Or (for personal development) you could switch to local workspaces, in which multiple checkout is by default.
I have 2 p4v set up on Windows and Linux. I was wondering if I can edit the code on Windows, create a pending changelist (this changelist belongs to a p4_windows_client). Then switch to Linux, which opens another p4_linux_client, to merge Windows pending changelist in order to build the project on Linux. The reason to have 2 different client {p4_windows_client, p4_linux_client} is because the root folder path issue as one is like C:\p4clientRoot, another is /home/p4client-root. I was wondering if this is possible?
I tested it, it seems like upon creating a pending changelist, the server will get that new changelist with only basic info, like change number, description, files being checked out. But it doesn't include the changes in the code being made on Windows box. So I feel it's unlikely to send over the change to Linux through this way.
You cannot change the owner of the pending changelist changelist, however you can shelve the changelist in from first workspace and then unshelve it in the second workspace.
For more information check the Perforce Manual for the p4 shelve command and p4 unshelve command.
The best way I have done dual development on windows and linux is to make 1 workspace, and use the "alt roots" line in your workspace. I make both my windows machine, and linux machine access the same share/drive. If it's dual boot, make a fat32 partition so both OS's can access the same drive, if they are 2 separate machines, create a network share on the machine you use most often, or on some network machine somewhere. Then make root and alt roots point to the same folder/share.
You also need to make sure that you blank out the Host line of the workspace so it can be used in both locations.
Now you can check out, edit, switch machines, and submit on the other machine.