I was trying to submit the Unreal Engine (250k files) to the depot via p4v, however, one day passed and it seemed like the submit was still doing some operations or was hung. To get more verbosity, I then used the p4 submit -c #number to commit via cli and I've realized that it got stuck on a pdb file.
add //test/test/Engine/Binaries/ThirdParty/Mono/Mac/lib/mono/gac/Microsoft.Build.Tasks.v12.0/12.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Tasks.v12.0.dll#1
add //test/test/Engine/Binaries/ThirdParty/Mono/Mac/lib/mono/gac/Microsoft.Build.Tasks.v12.0/12.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Tasks.v12.0.pdb#1
add //test/test/Engine/Binaries/ThirdParty/Mono/Mac/lib/mono/gac/Microsoft.Build.Tasks.v4.0/4.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Tasks.v4.0.dll#1
add //test/test/Engine/Binaries/ThirdParty/Mono/Mac/lib/mono/gac/Microsoft.Build.Tasks.v4.0/4.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Tasks.v4.0.pdb#1
add //test/test/Engine/Binaries/ThirdParty/Mono/Mac/lib/mono/gac/Microsoft.Build.Utilities.Core/14.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Utilities.Core.dll#1
add //test/test/Engine/Binaries/ThirdParty/Mono/Mac/lib/mono/gac/Microsoft.Build.Utilities.Core/14.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Utilities.Core.pdb#1
add //test/test/Engine/Binaries/ThirdParty/Mono/Mac/lib/mono/gac/Microsoft.Build.Utilities.v12.0/12.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Utilities.v12.0.dll#1
add //test/test/Engine/Binaries/ThirdParty/Mono/Mac/lib/mono/gac/Microsoft.Build.Utilities.v12.0/12.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Utilities.v12.0.pdb#1
add //test/test/Engine/Binaries/ThirdParty/Mono/Mac/lib/mono/gac/Microsoft.Build.Utilities.v4.0/4.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Utilities.v4.0.dll#1
add //test/test/Engine/Binaries/ThirdParty/Mono/Mac/lib/mono/gac/Microsoft.Build.Utilities.v4.0/4.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Utilities.v4.0.pdb#1
add //test/test/Engine/Binaries/ThirdParty/Mono/Mac/lib/mono/gac/Microsoft.Build/12.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.dll#1
add //test/test/Engine/Binaries/ThirdParty/Mono/Mac/lib/mono/gac/Microsoft.Build/12.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.pdb#1
add //test/test/Engine/Binaries/ThirdParty/Mono/Mac/lib/mono/gac/Microsoft.Build/14.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.dll#1
add //test/test/Engine/Binaries/ThirdParty/Mono/Mac/lib/mono/gac/Microsoft.Build/14.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.pdb#1
add //test/test/Engine/Binaries/ThirdParty/Mono/Mac/lib/mono/gac/Microsoft.Build/4.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.dll#1
add //test/test/Engine/Binaries/ThirdParty/Mono/Mac/lib/mono/gac/Microsoft.Build/4.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.pdb#1
add //test/test/Engine/Binaries/ThirdParty/Mono/Mac/lib/mono/gac/Microsoft.CSharp/4.0.0.0__b03f5f7f11d50a3a/Microsoft.CSharp.dll#1
add //test/test/Engine/Binaries/ThirdParty/Mono/Mac/lib/mono/gac/Microsoft.CSharp/4.0.0.0__b03f5f7f11d50a3a/Microsoft.CSharp.pdb#1
Is there anything that is odd? How would I debug this?
Related
I am facing a weird behavior in perforce submitted files, after p4 integrate
Scenario
Repo contains C# code and the built DLL. I wished to integrate a changeset from one branch to another
so I am following the steps which I had discussed, a while ago
The .cs files doesn't complain. If there is resolve conflict in the DLL, I choose either of Accept Source or Accept Target without much care. Reason being, I always rebuild the DLL before submitting
Issue
The DLL which was built in local workspace and reflected in the changeset is correct. I tested it locally and do p4 submit. But to my amazement, the DLL submitted is not the one which I had built. Instead the one which came from that other branch was submitted
Confusion
I thought that with perforce, when a file is opened in a changeset, always the latest(local) copy will be submitted. That is why I don't pay much attention if there are conflict reported in DLL
Isn't that correct ?
Why would the submitted file be different from my workspace version ?
When you "accept source" you're recording that you want the target file to be an exact copy of the source file; consequently, if you submit the file, it's not even transferred from the workspace (in order to save time) -- instead it's just copied server-side. If you tampered with the workspace file, this leads to the situation you describe where the workspace is now inconsistent with the depot, just like if you'd modified a file that wasn't open for edit.
If you submit with the -t flag (for "tamper checking"), it will check for tampered files by comparing what's in your workspace with what should be in your workspace according to the resolve options you picked:
C:\Perforce\test\integ>p4 integ source target
//depot/integ/target#2 - integrate from //depot/integ/source#3
C:\Perforce\test\integ>p4 resolve -at
c:\Perforce\test\integ\target - vs //depot/integ/source#3
//Samwise-dvcs-1509687817/integ/target - copy from //depot/integ/source
C:\Perforce\test\integ>echo tampertampertamper >> target
C:\Perforce\test\integ>p4 submit -t -d "submitting tampered file"
Submitting change 190.
Locking 1 files ...
integrate //depot/integ/target#3
//Samwise-dvcs-1509687817/integ/target tampered with after resolve - edit or revert.
Submit aborted -- fix problems then use 'p4 submit -c 190'.
Some file(s) could not be transferred from client.
If you p4 edit the file, it's changed from a pure copy to an edit, and will be read from the workspace instead of from the source file:
C:\Perforce\test\integ>p4 edit target
//depot/integ/target#2 - reopened for edit
C:\Perforce\test\integ>p4 submit -c 190
Submitting change 190.
edit //depot/integ/target#3
Change 190 submitted.
I am trying to integrate a branch with several files that were moved. They were not modified in target branch, yet appear as conflicts. When clicking "accept source" file silently disappears from conflicts dialog, but still remains marked as conflict in the changelist. One way I can fix this is adding -Di flag, but it's a big no-no on my team. I also tried p4 resolve through command line, with same outcome (no error or anything, but nothing is resolved).
What is going on and how can I resolve preserving the move history?
Do:
p4 resolve -as
from the command line. In the vast majority of cases that's all you need to do; it tells resolve to accept the change relative to the base (which means accepting the source in the case where the target hasn't changed).
(updating to include additional info from comment)
If after you do that you get an error like:
can't move (open for delete); must accept other resolve(s) or ignore
it means that the file was moved in the source (which means that normally a resolve -as would move the workspace file to match it), but the file in your workspace can't be moved because it's already open for delete (you can't move a deleted file). This is a pretty rare situation that happens if you move a file, delete it, and then try to resolve those two operations independently (but without submitting in between). In that case you probably want to specifically "ignore" the move resolve (like the error message suggests) by doing:
p4 resolve -ay
If you've somehow gotten your working file into a bad state (maybe you were running random commands before setting up the integrate and the workspace wasn't in a clean state) and either can't figure out how you got here or have no interest in doing forensics when you just want to do a basic integrate and forget about whatever you were in the process of doing before, you can always start over like this:
p4 revert FILE
p4 integrate -b BRANCH FILE
p4 resolve -as
If you have a file that was moved and then deleted in the source, it's not possible for both of those actions to be represented in a single changelist in the target, so the default is to ignore the move and accept the delete (on the theory that since the file is deleted anyway, it doesn't particularly matter where it's deleted):
C:\Perforce\test\movedel>p4 integ A/... B/...
//stream/main/movedel/B/foo#1 - integrate from //stream/main/movedel/A/bar#1,#2 (remapped from //stream/main/movedel/B/bar)
C:\Perforce\test\movedel>p4 resolve -as
c:\Perforce\test\movedel\B\foo - resolving move to //stream/main/movedel/B/bar
//Samwise-dvcs-1509687817/movedel/B/foo - ignored //stream/main/movedel/B/bar
c:\Perforce\test\movedel\B\foo - resolving delete from //stream/main/movedel/A/bar#1,#2
//Samwise-dvcs-1509687817/movedel/B/foo - delete from //stream/main/movedel/A/bar
Note that after resolving move we see an ignored and after resolving delete we see delete. Note also that the history of B/foo is linked to A/bar, which contains the history of the move, so the history isn't "lost", it's just not duplicated.
If you do want to duplicate the move history from the source into the target (so that the target, viewed independently of the source, shows the file as having been moved and then deleted), you need to do the integration in multiple submits:
C:\Perforce\test\movedel>p4 revert ...
//stream/main/movedel/B/foo#1 - was delete, reverted
C:\Perforce\test\movedel>p4 changes A/...
Change 316 on 2022/12/08 by Samwise#Samwise-dvcs-1509687817 'delete bar'
Change 315 on 2022/12/08 by Samwise#Samwise-dvcs-1509687817 'move foo to bar'
Change 313 on 2022/12/08 by Samwise#Samwise-dvcs-1509687817 'add foo'
C:\Perforce\test\movedel>p4 integ A/...#315 B/...
//stream/main/movedel/B/foo#1 - integrate from //stream/main/movedel/A/bar#1 (remapped from //stream/main/movedel/B/bar)
C:\Perforce\test\movedel>p4 resolve -as
c:\Perforce\test\movedel\B\foo - merging //stream/main/movedel/A/bar#1
Diff chunks: 0 yours + 0 theirs + 0 both + 0 conflicting
//Samwise-dvcs-1509687817/movedel/B/foo - copy from //stream/main/movedel/A/bar
c:\Perforce\test\movedel\B\foo - resolving move to //stream/main/movedel/B/bar
//stream/main/movedel/B/bar - moved from //stream/main/movedel/B/foo
C:\Perforce\test\movedel>p4 submit -d "integrate #315"
Submitting change 317.
Locking 2 files ...
move/add //stream/main/movedel/B/bar#1
move/delete //stream/main/movedel/B/foo#2
Change 317 submitted.
C:\Perforce\test\movedel>p4 integ A/... B/...
//stream/main/movedel/B/bar#1 - delete from //stream/main/movedel/A/bar#2
C:\Perforce\test\movedel>p4 submit -d "integrate #head"
Submitting change 318.
Locking 1 files ...
delete //stream/main/movedel/B/bar#2
Change 318 submitted.
What is going on
Perforce is not able to deal with moved files in merge/integrate properly. I can confirm that this is still an issue in the most recent version. We have this case regularly.
Say, team A is working on //OurDepot/ExclusiveContentOfTeamA/ and you are then merging that to team B's branch. Consider the case where team B has not touched (or even looked at) that location.
Merging should be a breeze in this scenario, right? Wrong!
If team A moved and deleted files, it is always a dice roll whether the merge will work or not. Most of the time "accept source" will resolve the issues, but sometimes you get the state you described in your question.
and how can I resolve preserving the move history?
You can't. All you can do is some hacky solution forcing perforce to delete the files (p4 resolve -ay), and then manually repair the state in the branch by re-adding the files as new files. History will be lost.
I am creating a server that handles version control of files in server and let the client view them at specific commit if they wanted.
The way I implement this is that when user clicks a specific commit, I call checkout [hash of commit] to revert the file back to what it was and then read from that file.
The problem is that two people may be trying to read different commits of the same repository at the same time, meaning the state of file may change while reading from the file.
I tried checking out another commit while reading from it and it seems to work okay but I cannot be sure when the it is scaled.
I am using nodeJS and express for my server. When nodeJS starts reading file, will it still be the same state as the point when it started reading or would it change along with the change that is forced by git if I checkout another commit while reading the file?
Instead of using checkout, consider show:
git show <commit id>:<filename>
This will print the contents of the file at that commit. If you absolutely need it in a file, generate a unique temporary filename and redirect the output:
git show <commit id>:<filename> > tmpfile_uniquesuffix
I am using following command to sync B vob files from A vob
clearfsimport -master -follow -nsetevent -comment $2 /vobs/A/xxx/*.h /vobs/B/xxx/
It works fine. But it will check in all the changes automatically. Is there a way to do the same task but leave the update files in a check out status?
I want to update the file for B from A. Build my programme, and then re-cover the branch. So if the updated files is an check out status, I can do unco later. Well with my command before, everything is checked in. I cann't re-cover my branch then.
Thanks.
As VonC said, it's impossible to prevent "clearfsimport" to do the check in. And he suggested to use a label to recover back.
For me, the branch where I did "clearfsimport" is branched from a label.Let's call it LABEL_01. So I guess I can use that label for recovery. Is there an easy way (one command) to recover the files under /vobs/B/xxx/ to label LABEL_01 ? I want to do it in my bash script, so the less/easy the command is, the better.
Thanks.
After having a look at the man page for clearfsimport, no, it isn't possible to prevent the checkins.
I would set a label before the clearfsimport, and modify the config spec for the new version to be created in a branch (similar to this config spec).
That way, "re-cover" the initial branch would be easy: none of the new version would have been created in it.
I'd like to automate TortoiseSVN as part of a commit process.
Specifically I'd like to dynamically create a log entry for the commit dialog.
I know that I can launch the commit dialog either from the commandline or by right clicking on a folder and selecting svncommit.
I'd like to use the start commit hook to setup a log entry.
I thought this worked by passing an entry file name in the MESSAGEFILE variable but when I add a hook script it cannot see this variable (hook launched successfully after right clicking and choosing svncommit).
When I try using the commandline I use the /logmsgfile parameter but it seems to have no effect.
I'm using tortoisesvn 1.5.3.
Looks like it was my own misunderstanding of the the API that caused by a problem.
Solution:
1) I've added a start commit hook script to TortoiseSVN using the hooks gui in the settings area of the right click menu.
2) The script receive 3 pieces of information: PATH MESSAGEFILE CWD
For details see: Manual
These are passed as command line arguements to the script - for some reason I had thought they were set as temporary environmental variables.
My script then simply opens the file specified by the second arguement and adds in the custom text.
When the commit dialog comes up the custom text is there.
3) Best of all if tortoisesvn is launched from a script directly into the commit dialog:
e.g. [ tortoiseproc /command:commit /path:. /closeonend:1 ]
The hooks are still called.
If you just need a static template, set the tsvn:logtemplate property.
For dynamic generation, the /logmsgfile parameter does work, but it seems to need the full path. A batch file that looks like the following might work for you.
GenerateLogMsg.exe > tmp.msg
"C:\Program Files\TortoiseSVN\bin\TortoiseProc.exe" /command:commit /path:. /logmsgfile:"C:\Documents and Settings\User\My Documents\Visual Studio Projects\Project\tmp.msg"