Showing posts with label error. Show all posts
Showing posts with label error. Show all posts

Monday, 8 November 2010

error using perforce within emacs

hi - I've obtained p4.el and put the following in my .emacs, running under cygwin:

(setq p4-executable "p4")(load-library "p4")

p4.exe is the cygwin version.

On running M-x p4-info I get the following error:

/path/to/p4.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory

Yet running M-! p4 info works fine. Probably I'm missing an env variable. Apologies if this is a basic question - I'm new to emacs.


View the original article here

Sunday, 7 November 2010

Sequence error: local change vs remote

What does "Sequence error: local 'change' counter vs remote" mean? Why am I getting "Sequence error" when trying to submit a file to the server?


A "Sequence error" occurs when the change counter is altered before a submit of an existing pending numbered change.  Changelists should always appear in a sequential order, and this error means that the sequence is potentially out of order. If you see this error, contact Perforce Support immediately and shut down your Perforce Server.

Note: Carrying on with this error in place could cause further damage to the information stored in your Server.

The sequence of events that generates this error, is as follows:
Create a pending numbered changeForce the change counter to a number below the pending change numberAttempt to submit the pending numbered changeFrom the error reported, local refers to the current change counter value and remote the value of numbered pending change.  For example: p4 submit -c 221Submitting change 221.Locking 1 files ...edit //depot/main/jam.c#4Operation 'dm-CommitSubmit' failed.Sequence error: local 'change' counter '100' vs remote '221'!Here the change counter has been set to 100 whereas the pending numbered changelist created before the change counter was changed was change 221.

View the original article here

Friday, 5 November 2010

"Client can only be used from host" error

After getting a new PC, I am getting the following error when running commands:

Client 'workspace1' can only be used from host 'pc1'How can I fix this error?

The "Host:" field of the client workspace specification can be removed or changed to the new hostname. Please be aware that by default a client spec is tied to a client host. It is bad practice to share a workspace across client hosts.

The Host field can be changed by running the p4 client command from the command line. Or through P4V, go to View->Workspaces and edit the workspace in question.


View the original article here

Wednesday, 3 November 2010

Sync error with utf16 filetype

When syncing or reverting a utf16 file, I am getting the following error:

Translation of file content failed near line 1

In 2007.2 release, a new utf16 filetype was introduced. When a file is added using a 2007.2 or greater client to a 2007.2 or greater server, Perforce looks for the UTF16 BOM (the 2 first bytes of the file), if there is a match the file will be detected as "utf16".

On submit, a unicode translation from utf16 to utf8 takes place and the file is stored on the server in utf8 regardless of whether the server is running in internationalized mode or not.

To take full advantage of the "utf16" filetype feature, a 2007.2 client (or higher) is required. Utf16 files added by pre-2007.2 clients are detected as binary and utf16 files synced by pre-2007.2 clients will be stored on the client in utf8.

A problem might arise after adding a utf16 file with a 2007.2 client (or higher) and submiting the file with a pre-2007.2 client. As the file will be sent without any utf16 to utf8 translation, the file will be stored on the server in utf16, causing the translation error on sync as well as a revert, as the depot file is not in utf8 as expected. A variant of this issue will happen when checking out a utf16 file with a pre-2007.2 client, then changing the utf8 content of the synced file to utf16. Upon submit, the "Translation of file content failed" errors will be shown.

To fix this issue, the filetype of the problem revisions needs to be changed to "binary" using the unsupported p4 retype command (see p4 help retype for details):

p4 retype -t binary

To detect which depot files might be affected by this issue run:

find -type f -name '*,v' | xargs grep -al $'\xFF\xFE'

Note: find, xargs, and grep are Unix commands and not natively available on the Windows environment. External Windows ports of Unix tools might allow you to run these commands within the Windows environment.

To avoid seeing this issue in future, all users should upgrade their Perforce client to the latest release.


View the original article here