I like to verify a question with Perforce users:
In your own workspace in perforce, you check out a file, and save it, but do not check it in yet. This saving shouldn't be globally visible to everyone, right? Since each has his/her own workspace. A colleague thinks that it's globally visible to everyone; even if I haven't checked it in. Your opinion is appreciated.
I thought that is what workspace is for.... buffering and isolating one's play area.
When is the situation above (ie, saved but not checked-in) globally visible to everyone?
(Caveat: Everyone is downloading source-codes into their workspace from the same root branch)
Correct, the changes are pending thus not visible to everyone yet and are only on your local OS workstation.
In Perforce, users can see all opened (checked out) files 'p4 opened -a' - however the actual content of the changes are not visible to everyone. A user would have to shelve their checked out file changes if they wanted other users to be able to access that file that was modified on their workstation.
EXAMPLE
$ p4 opened -a
//depot/Jam/MAIN/src/Build.com#7 - edit default change (text) by testguy#testguy14nstreams
//depot/r1.0/bar#1 - edit change 12119 (text) by testguy#testguy14nstreams
//depot/r1.0/foo#1 - edit change 12119 (text) by testguy#testguy14nstreams
//depot/www/dev/Jam.html#2 - edit change 12116 (text) by admin#admin14streams
//depot/www/dev/Jambase.html#2 - edit change 12116 (text) by admin#admin14streams
//depot/www/dev/Jamfile.html#3 - edit change 12116 (text) by admin#admin14streams
//depot/www/dev/Jamlang.html#2 - edit change 12116 (text) by admin#admin14streams
//depot/www/dev/images/jamgraph-jam.gif#1 - edit change 12116 (ubinary) by admin#admin14streams
//depot/www/dev/index.html#3 - edit change 12116 (text) by admin#admin14streams
REFERENCES
Shelving work in progress
http://www.perforce.com/perforce/doc.current/manuals/p4guide/chapter.files.html#d0e5537
'p4 opened' command
http://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_opened.html
Related
I'm new to perforce and somehow I've gotten myself into a weird state.
I have two files that I modified and somehow added to a change list (not the default changelist). I want to revert the changes and delete the changelist but I can't figure it out.
I have tried doing this:
p4 change -d 75697
Change 75697 has 2 open file(s) associated with it and can't be deleted.
So I tried to revert the files in the change list:
p4 revert package.json
package.json - file(s) not opened on this client.
Okay, so I guess I need to open the file?
p4 edit package.json
//a/b/c/package.json - can't edit (already opened on this client)
So I can't revert the file until I open it but I can't open it because it's already open? What's the deal?
You could be getting that error because your local package.json doesn't map to the actual depot path that's open (due to something tricky you've done with your client view since opening the file). It's hard to say without seeing more command output, but try just:
p4 revert -c 75697 //...
to revert all files in that changelist regardless of their paths.
If that doesn't work, check with your Perforce admin; either they've put you into some really weird permissions bind (i.e. they've revoked the access level to the files that you need in order to revert them) that they should undo, or they'll need to do a bit of light db maintenance (p4d -xf 925) to fix an inconsistency.
I'm trying to merge main stream to development stream and some files need to be resolved. On resolve I have an error:
filepath tampered with before resolve - edit or revert.
I tried to solve it as described here, but without success.
This is what verify command shows me:
for the target
filepath - branch change 9070 (text) A3269695246A89D21F341D8A5BB70B5B
for the source
filepath - edit change 22793 (text) 171BA2F3E0FFCEF3F7A34FDB7A2CEF69
filepath - add change 9049 (text) A3269695246A89D21F341D8A5BB70B5B
What do branch change, edit change, add change mean? Why is the MD5 identical but I still have an error? How to solve?
Perforce's client-server architecture is confusing you a bit here: the 'verify' command is reporting on the state of the files on the server, but the 'tampered with before resolve' message from 'p4 resolve' is alerting you to a problem with the state of the files on your client.
It appears, from the little bit of information that you provided, that:
Change 9049 added the source file, with digest A3269...
Change 9070 branched that source file to the target. Of course, the digest is the same for source and target, since the branch was a perfect copy of the file.
Change 22793 modified the source file, and hence its digest changed
You are then trying to integrate change 22793 from the source to the target.
This integration would be a straightforward "safe resolve" in most cases, because the file was changed only in the source, and the target was a perfect copy of the previous revision of the source.
However, the resolve command looked on your actual workstation copy of the target file, and discovered that the file that you have there is not a file with digest A3269...
Since the 'resolve' command was just about to replace your copy of the target file on your workstation with the merged result, it doesn't want to do that if there is a possibility that you made changes to that file (without opening the file for edit) that you don't want to lose.
So 'resolve' is trying to tell you to have a look at the copy of the target file that is currently on your workstation (using your text editor, e.g.), and see if you actually made changes to that file.
If you did, and you want to save those changes, then you can't perform this integration at this time; you need to instead open the file for edit (using 'edit -k' to retain your modified copy of the file, of course) so that Perforce can merge your edited copy with the changes from change 22793.
If you didn't make changes to the target file, or if you made changes but you don't want them, then you need to discard those changes explicitly, for example by:
reverting the pending integration to the target file
Running 'p4 sync -f target-file'
This is the sort of information that 'resolve' is trying to communicate in that very terse
filepath tampered with before resolve - edit or revert.
I also have faced this issue while executing p4 resolve -am for some file. the solution is to do p4 edit <filename> and then execute p4 resolve -am for that file.
It means that your local was edited without the app knowing about it (e.g., you forgot to do "p4 edit" first). I believe I've seen this when doing an integrate then changing the file before submitting it, too.
On P4V windows app,I can select a particular user and a workspace and see the user's list of changes on that particular workspace. When I click a particular changelist from the list of changes, I can see the changed files under the 'Files' tab and then see the actual revisions for a particular file.
For some reason I cannot see the revised file named in some rare cases and when I click on files tab I see a message saying changes might protected or obliterated. Is it possible to do something to prevent other users from finding out what changes you have made for a particular changelist?
Yes it is possible. A changelist may be marked either public or restricted, and a restricted changelist requires permission to view: http://www.perforce.com/perforce/r10.2/manuals/cmdref/describe.html#1040665. It is the 'type' of the changelist that controls this: http://www.perforce.com/perforce/r10.2/manuals/cmdref/change.html#1040665
How can I instruct Perforce to merge changes into an existing, open, and modified file in the workspace when unshelving a file shelved in the depot? The only options that Perforce appears to offer the user is to overwrite or revert the existing file in the workspace, but this does not allow, for example, to unshelve and integrate changes to the same file from multiple change lists. Is there a way around this limitation?
What I typically do is right-click on the shelved file and select "Diff Against Workspace File". When you open up the Diff tool, you can select a button in the toolbar to "Edit file in right pane". This essentially starts a two-way merge. With each difference you can select the changes you want from the shelved file (differences are selected from the workspace file by default).
However, it would be nice if Perforce added a type of merge feature to do this more automatically.
Edit to add:
Perforce now has a built-in capability to merge files when unshelving. If the user unshelves a file that is also checked out, and "Revert checked out files before unshelving" is unchecked, Perforce will mark that file for resolve. I looked through the release notes and was not able to find in which version this capability was added, but based on this link (see near bottom of p4 unshelve description), it was added no later than 2012.1.
Edited again to add:
That feature was added in release 2011.1 of the server. Here's the release note:
#299614 (Bug #38221, #39099) **
Unshelving a file opened for edit over a file already opened
for edit in the workspace is now allowed. A resolve record is
created when unshelving, and the user must then run 'p4 resolve'
to resolve the workspace files with the shelved files.
If you checkout your file, and then try to submit it, it will give you the option of getting the latest revision without replacing your copy. Then it will subsequently will give you the ability to run a merge tool, where you must resolve any conflicts before submitting.
Using P4V 2009.2.
I have used P4Win in the past, but this is a new setup for me.
The problem is that the files I have checked out disappear from the changelists, so I cannot check them in.
To reproduce:
Check out a file, make a change to it.
Go to the 'pending changelist' tab.
There will be a + sign on the default changelist.
Click on the plus, or on the changelist line, the plus will disappear, there will be nothing in the changelist.
Try to check the file in by right-click on the file itself, the changelist dialog will show up but NO files are listed.
You can transfer the file to a new changelist, the same thing happens.
Looking at the file in the 'checked out by' window does correctly show the changelist number & description.
It sometimes happens to me, and what I normally do is change workspace and then change back again. Not sure if there is an easier way to get it to realise the files are checked out.
the only thing I can imagine is that you are looking at a different client workspace. Notice that the "Pending Changes" tab has a filter on the top, where you can separately filter for folder/files, user and workspace. Maybe the filter is set to something so that it doesn't match the client workspace where you have actually checked out the file.
Good luck,
Henrik
You may get this if the perforce server has not been upgraded. Old versions of P4D have this error: http://kb.perforce.com/article/1167/opened-files-missing-in-default-changelist
If that is not an option, use p4Win.
I agree with jhwist,sounds like your looking at a different client spec.
P4V is a bit confusing on this front, IMO and I personally prefer P4 Win but to check, open up a command prompt and type p4 changes -s pending -c YOURCLIENTSPEC - chances are that the changes you think you have aren't in your current clientspec
This can happen sometimes and in my experience it is a refresh issue with p4v. Often simply closing the pending tab or reopening p4v solves the problem.
In my case, the pending List has over 4000 files, (due to eclipse created so many files after mvn tasks) so none of them are shown. I created a different pending list, then cleared all contents, then moved the files to the new change list. Then it is appearing in the new change list.
Modify the file directly in the correctly mapped client folder (i.e. your current workspace). You will see the changelist for sure. As jhwist mentioned clear filters if any and choose your current workspace (since you may have many)