I am trying to make a review of change shelved with command line client. My friend created new file and added it with p4 add filename. Then it was shelved (p4 shelve). Then, on our Swarm website he found his change and clicked "Request Review" and added me as a reviewer. I can see view the review, comment changes, vote, but I cannot approve, reject, commit changes - the button "Needs Review" is disabled. What am I doing wrong? Thank you for all the answers!
It's possible his change is part of a Swarm "project." Only project members can approve changes that touch the project.
You can tell if the change is part of a project by looking at the review heading - there's a line which says "myfriend authored this 2 days ago for ". If is a project name, you must be a member of that project to approve. If it's just a depot path, then there's probably some other reason.
Related
If I submit a changelist in Perforce by creating a new swarm review, the changed files are deleted from my local workspace.
After the changelist is accepted the files reappear (get downloaded?) to my workspace again.
How can I submit a review but keep the files in my workspace so I can work with my changes locally?
(Right now I have to wait until the swarm review is accepted to continue with my work)
maybe it has something to do with the "Shelve files" option?
Thanks alot :)
I just found my error.
The files are not deleted but shelved (they are stored in the remote repository but I cannot access them locally as the change is not approved
Simply do not shelve the files on a new swarm request.
I don't have admin privileges. Need to test other's change lists and submit them.
Tried changing the owner of the CL but didn't work without admin.
p4 change -U <creator> <CL>
Error in change specification.
Change <CL> can only be updated by user <creator>
Unshelving the original CL, then testing it, will create a duplicate CL. Duplicate CL is submittable but not the original CL.
Are there any ways to submit a perforce change list of another user without admin privileges?
Based on documentation I'd say no (see below). The way you are doing it is probably the best way using shelving. Another option would be to have an unstable branch that code is okay to be broken and another user can 'release' after testing to a stable branch.
From my understanding, changelists are owned by the user and not really "transferable" like you want.
From Helix 2020.2 documentation on the p4 change command
The owner of an empty pending changelist (that is, a pending changelist without any files in it) can transfer ownership of the changelist to another existing user either by editing this field, or by using the -U user option.
If you start down the "sharing a workspace" path. Don't. "It is actively discourages by Perforce Technical Support" and "it is almost never a good idea to share a Perforce client workspace among multiple users" https://community.perforce.com/s/article/3675
I would like to integrate Redmine with SVN in a manner that the commit message automatically gets posted in the Redmine Ticket ID. Kindly let me know if there are any plugins or hooks up which can be used for me to achieve the same
Such functionality is built in.
Go to Admin | Settings click on Repositories tab, and there you will see following section:
Referencing and fixing issues in commit messages
Referencing keywords
By default, there are:
refs,references,IssueID
So when you perform svn commit, and say
refs #23
such change will be displayed on issue no=23, once you refresh repositories and visit issue again.
There is also way to automate it, so svn or git, post-commit hook refreshes repositores for you...
Full doc here: http://www.redmine.org/projects/redmine/wiki/HowTo_setup_automatic_refresh_of_repositories_in_Redmine_on_commit
Such way if you track changes, you can see all code that was changed, regarding some issue...
For example:
And you can click on (diff) to see that particular code...
Then, furthermore, you can copy URL's when you click diff, so you can discuss code with your peers...
Cheers :)
I use P4V. Once I changed logged user I saw only empty folder in one of workspaces and I couldn't load any content. So I marked this empty folder to delete - it made relevant changelist but didn't remove this folder from workspace. After some other tries I finally managed to connect with correct workspace. As the changelist has not been needed anymore I deleted it. Then I expanded the workspace content and what I saw was all files marked for delete. We tried to unmark them but we didn't manage to do so. So we marked all them once again to delete to create a changelist as we wanted then revert this hoping it will remove to-be-deleted marks. Suddenly P4V started removing all files from the project! Then I stopped the application and once run again I reverted this changelist. Ok, files have been restored BUT on all of them to-be-deleted mark from previous operation is still visible - even for other users in other locations. Does anyone know how to remove this mark?
Select the file, go to the "Files" pane on the right-hand side, and click the "Checked Out By" tab. This will show you what user and workspace has the file opened for delete, and in what changelist. You can go to that workspace and "revert" the file, or you can delete the workspace -- either way that workspace will no longer have the file open and the blue mark will go away.
Our user performed an integration between branches.
Integrated files were placed in a pending changelist but they are invisible when I look
at this changelist in p4v.
I can see them when I look on this changelist when I connected to another workspace, I can also see then in Eclipse.
When I choose to Resolve conflicts on this changelist it works too, but
when I try to submit the changes, there is nothing there.
After I installed a new version of p4v, the problematic pending
changelist appeared with a question mark (red triangle with a question
mark).
Any Ideas?
Thanks.
Answer from Perforce support:
This may be a working and locks out of sync
issue. Can you run the following server command:
p4d -r $P4ROOT -xf 925
Where "$P4ROOT" is the location of the db.* files.
P4V.exe allows the user to specify a filter on his workspace. Perhaps the workspace had a filter applied, such that the GUI did not show the files, where the command line client and others (ie Eclipse) would not be privy to this filter and would show the files.
Another possibility is that the user was logged in under a workspace other than his default, and the files were checked out in his default workspace. It would be easy to then find these files in his default by looking at pending changelists for all users.