I've set up a new workspace in /Users/sylwester/test and checked for get all revisions and switch to workspace. Every time i start p4v and select my workspace after login I get this error. The command it says it has performed is:
p4 changes -s submitted -l -m 100 /Applications/...
The p4v executable is of course in the /Applications/ directory but my workspace in /Users/sylwester/test. To be sure it was not fixed at a later version i upgraded p4v to 2017.2 (P4V/MACOSX1011X86_64/2017.2/1518788)
It sounds like you have a filter somewhere (probably the history or submitted changelists tab?) that specifies /Applications/... as the path. If you clear or fix that I'd expect the error to go away.
Related
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 ....
I just merged a directory and am doing a TortoiseSVN diff to check for changes before committing. I can see from the file explorer that I have modified several files, but I can't see anything from the diff, only the propinfo. It seems I modified svn:mergeinfo while merging, and that is all the diff is showing me.
How do I see the actual files that have changed??? Using Kdiff3 vs TortoiseMerge doesn't make a difference.
TortoiseSVN version 1.9.7
When propinfo is modified, TortoiseSVN apparently only shows this propinfo when diffing a directory, if you use "SVN diff" from the context menu.
You can work around this by using Check for Updates from the context menu rather than SVN diff.
This works because "Check for Updates" appears (?) to be equivalent to the command TortoiseProc.exe /command:diff /path:. /ignoreprops, while "SVN diff" does not pass the ignoreprops flag.
I am trying to look up history for a workspace in p4v. I believe I changed the root directory at one point, and the updated root is shown in the workspace info from p4v and from command line. However, I get the following when I attempt to review history.
Path 'c:\path_to_old_root\...' is not under client's root 'c:\path_to_new_root'.
The Perforce command run is:
p4 changes -s submitted -l -m 100 c:\path_to_old_root...
Additionally, when looking at the workspace in the selectro on the left side pane it shows c:\path_to_old_root\ for the local directory.
I am unsure why it is the generating the command/determining local directory to use in the manner it is.
Not sure why this occurred, but it appears files in the .p4qt directory were not correctly updated. Based on the suggestion that deleting said directory might be helpful, I searched the directory for occurrences of the old root path and replaced them with the new root path. This appears to have corrected the problem.
I'm using a newly installed Linux Mint and attempting to develop with Sublime Text 3.
I've installed p4v, p4 and ST3.
I've created a P4CONFIG in the workspace folder that contains the P4PORT, P4CLIENT and P4USER variables and their appropriate values.
I've added the Perforce.sublime-settings files to my ~/.config/sublime-text-3/Packages/User folder that contains the other ST3 plugin settings.
The settings include "perforce_auto_checkout_on_save": true.
I've gone to terminal in the relevant folder I am trying to edit and ran the p4 info command and it seems to recognize the server and workspace I am trying to access.
No matter what I do, I am still unable to login using the Perforce: Login command and the appropriate password. As a result, when I save, it doesn't check out the files.
Please help me get this working. I really want this to work.
Thanks
I had the same issue on a mac OSX (Yosemite). p4 was installed in /usr/local/bin. .bash_profile included same in $PATH. p4 would execute from fresh bash session.
Problem was resolved when I made a symbolic link in /usr/bin:
$ cd /usr/bin
$ sudo ln -s /usr/local/bin/p4 p4
$ ls -l p4
lrwxr-xr-x 1 root wheel 17 Jul 26 17:05 p4 -> /usr/local/bin/p4
If you have p4 in a non-default location the binary won't be found and any plugin commands will fail. (Unfortunately the error reporting by the plugin is misleading, saying that the file is not under the client's root.)
On OSX, the Perforce plugin prepends its shell environment with .bash_profile, so you have a chance to tell the shell where to go to find p4 by being explicit there:
export PATH=/usr/local/bin:/usr/bin:$PATH
I had the same issue, and after adding the line above (I have p4 under /user/local/bin) the plugin began operating normally.
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