Whenever I get error from perforce server it's printed as question marks.
I want to resolve this by setting client to english language without charset (default locale).
But even if I delete utf8-bom from WorkspaceSettings.xml it gets repopulated after quitting P4V visual client. After opening command line in P4V it shows P4CHARSET=utf8-bom. I don't have environment variables so I don't know where it gets utf8-bom value. It would be ok but this charset does not work for me.
Is this possible to revert behavior to default english locale?
Perforce Server version: P4D/NTX64/2012.1/473528 (2012/05/31)
P4V 2015.1/1233444
It turns out this is a problem with OS messages, not perforce messages. OS produces localized error message, perforce server encodes it incorrectly. I suppose this can be solved by setting perforce server to UTF8.
But we use a workaround:
P4V client version June 2011 somehow works correctly with server in this situation.
Related
I'm using pgAdmin 4 (v. 6.12) on Windows 10.
Since (I believe) version 6.10 I've noticed that autocomplete always shows up. I tried to change preferences settings to only show it on Ctrl + space:
But it made no difference - autocomplete is always shown.
Then I've noticed, that some other settings are not respected, for example insert bracket pairs:
This is how editor looks just after typing opening bracket:
This is very annoying. I've completely removed previous installation of pgAdmin: uninstalled it, deleted all files and folders with pgAdmin in name and did the same in Windows registry. But new installation behaves the same.
New installation was made only for my user account, not for Anyone who uses this computer option.
Like you, I was also unable to turn off autocomplete-on-type after installing 6.12.
When using the web client, I was able to log out and log back in to solve it.
UPDATE from comments: using the Windows application, Adam was able to clean session data from the registry, open the editor window, change settings, close editor window, change settings… And it started to work again.
More details...
It happened to me in Ubuntu when I first upgraded to 6.12 and restarted the server, while the client was connected. The web client appears to have held on to a session that at first seemed to work. Once I logged out and log back in, my autocomplete-on-type OFF setting was respected again.
I agree that this bug is completely frustrating. I'm not sure why anyone would want the autocomplete-on-type setting enabled, pgadmin4 is unusable with it on.
I have a project I am going to begin co-developing on one of my web servers. Due to the nature of this kind of thing I'd like to have some version control going on. I've been searching all day for something that fits my needs and Bazaar seems the way to go, but I cannot figure out how to configure it.
My web host is Linux, without SSH (or SFTP as far as I can tell). I've read that you can use Bazaar in this situation to make a "dumb" server, but I can't for the life of me figure out how to configure, or find a guide. Everything out there requires either SSH/CLI access (both of which I don't have) or are too vague to follow. I am using the Windows GUI for Bazaar as well.
Can anyone either point me to a guide/instructions on how to do it, or post one here?
Edit Since Original Post
I have been trying to do several things since my original post. It might be that I am misunderstanding how bazaar is meant to work. What I want is to have my php files etc. on my web host (to which i do not have ssh access) so that myself and codevelopers can edit and test files without overwritting each other.
I initially tried to "start a new project" on my server via "ftp://user:pass#server" and it says that is successful. Then it prompts with a "Unable to open location" error saying "C:/ftp:/user:pass#server is not a brand, checkout, or repository.
Do you want to open it as a virtual repository, searching for nested locations?"
When I hit yes, it gives me an error "Unable to change to C:/ftp:/user:pass#server - closing page."
if I do the same thing with the "Open an existing location" option, it gives me the same error, except afterwards the Bazaar GUI hangs with "Not Responding" and needs to be killed.
Either way nothing is created that I can then interact with in Bazaar. If I create a local project and then push, it all seems to work. However, if I try to commit changes so I can push them I get an error "Bazaar has encountered an environmental error. Please report a bug if this is not the result of a local problem at https://bugs.launchpad.net/qbzr/+filebug including this traceback, and a description of what you were doing when the error occurred." the show details says "bzr: ERROR: Unable to determine your name.
Please, set your name with the 'whoami' command.
E.g. bzr whoami "Your Name ""
Before you can commit revisions, you need to set a name and email address. These are important metadata in a commit. You can set these in the Settings | Configuration | User Configuration menu. On the General tab enter the Name and E-mail fields. It's recommended to use real data in public projects, so that others who view your project can contact you in case they have questions. But it doesn't have to be real. This is a one-time initial setup.
As a next step, I would do a test to make sure you can really use your server over FTP, as a sanity check:
Commit a few revisions in your local repository, just so that you have something to push. It could be anything, doesn't matter.
Try a push to a URL in the format: ftp://user:pass#server/absolute/path/to/somewhere. In the example in your post you wrote ftp://user:pass#server, but it's important to have an absolute path there, like in this example.
If for some reason the push doesn't work well using the GUI, try it on the command line, for example:
bzr push ftp://user:pass#server/absolute/path/to/somewhere
This should really give an error message we can debug. In that case, paste the output into your question.
UPDATE
You said in comments that something was wrong with your name+email setting, and changing that resolved the problem. It would be nice to know what exactly was the problem there.
About bzr push to an FTP server, I double checked, this will never create the files on the server. From bzr push -h:
The target branch will not have its working tree populated because this
is both expensive, and is not supported on remote file systems.
Some smart servers or protocols may put the working tree in place in the future.
Over FTP it's a "dumb" server, so it definitely won't put the files there, only the .bzr directory, which is the repository and branch data. If you want to have the files there, I'm afraid you have to copy manually. There is a related bzr-push-and-update plugin, but it requires ssh access, which is not your case.
I like P4Win than P4V but it seems P4Win is not available in perforce.com.
Can anybody tell me where can I get P4Win?
Yes Perforce have discontinued P4Win, the replacement being P4V. The last version they released is available from perforce.com here:
ftp://ftp.perforce.com/perforce/r08.1/bin.ntx86/p4winst.exe
Of course it may not function correctly or some of the newer features of the perforce server such as streams will be unavailable.
All of a sudden, I'm getting the following message in the area where
my remote files used to be listed:
"To see the files in your repository you must define its Version
Control settings."
This is happening for multiple sites and the Version Control setting
is set to none (and it always has been).
I had another Dreamweaver author, try it on her system and she got to the remote server just fine. When I logged on to her system I got the same problem, but this time it said "FTP error...password problem..."--she's on Windows 7--I'm on XP. Our company does not support "version control." I can't find any "SVNs" lieing around either.
You will see this message when you are in the 'Repository View' and you haven't set up version control. You can check this in the FILES tab/window. If you don't see it press F8 or select Window/Files. Switch from Repository view to Local View, Test Sever, or Remote Server as appropriate.
Starting yesterday I have been unable to connect to our Perforce server. Expanding the depot gives the message "//depot ". Funny because I connected just fine last week and the folks sitting next to me can connect without problems.
IT says nothing the settings have not changed and no errors are being reported. It doesn't help that IT is multiple time zones away!
I'm hoping someone here has seen a similar problem and can tell me which switch to flip.
SOLVED: Using P4Win or P4V there are no errors. BUT using the command line p4.exe I get the error "protected namespace - access denied". Passed this onto IT and perforce mysteriously works again. Sounds like I got my permissions disabled and then re-enabled. No-one has owned up to anything but at least I'm up and running again!
Funny that I had to go to the command line before I got an error message.
"protected namespace - access denied" - means you have no permissions for the specified path. You should see this message in P4V output window if you have the detailed logging enabled.
One possibility is an administrator may have accidentally introduced a typo in your username whilst editing a group or the protection table, or removed you from a group, essentially removing your access (but easy to restore). The spec depot keeps changes to perforce server control files so an administrator could check to see what went wrong, but the spec depot does not tell you which administrator changed it. The spec depot must be created before the event.