Basic Perforce Command – P4 Command Reference

perforce-command-reference

Command

Description

p4 add
Open file(s) in a client workspace for addition to the depot.
p4 admin
Perform administrative operations on the server.
p4 branch
Create or edit a branch specification and its view.
p4 change
Create or edit a changelist specification.
p4 changelists
List submitted and pending changelists.
p4 changelist
Create or edit a changelist specification.
p4 client
Create or edit a client workspace specification and its view.
p4 clients
List all client workspaces currently known to the system.
p4 delete
Open file(s) in a client workspace for deletion from the depot.
p4 depot
Create or edit a depot specification.
p4 depots
Display a list of depots known to the Perforce server.
p4 describe
Provides information about changelists and the changelists’ files.
p4 groups
List groups of users.
p4 group
Add or delete users from a group, or set the maxresults, maxscanrows, and timeout limits for the members of a group.
p4 have
List files and revisions that have been synced to the client workspace
p4 info
Display information about the current client and server.
p4 integrate
Open files for branching or merging.
p4 integrated
Show integrations that have been submitted.
p4 job
Create or edit a defect, enhancement request, or other job specification.
p4 jobs
List jobs known to the Perforce server.
p4 label
Create or edit a label specification and its view.
p4 labels
Display list of defined labels.
p4 lock
Lock an opened file against changelist submission.
p4 login
Log in to a Perforce server by obtaining a ticket.
p4 logout
Log out of a Perforce server by removing or invalidating a ticket.
p4 passwd
Change a user’s Perforce password on the server.
p4 rename
Renaming files under Perforce.
p4 resolve
Resolve conflicts between file revisions.
p4 revert
Discard changes made to open files.
p4 set
Set Perforce variables in the Windows registry.
p4 submit
Send changes made to open files to the depot.
p4 sync
Copy files from the depot into the workspace.
p4 tag
Tag files with a label.
p4 triggers
Edit a list of scripts to be run conditionally whenever changelists are submitted, forms are updated, or when integrating Perforce with external authentication mechanisms.
p4 user
Create or edit Perforce user specifications and preferences.
p4 users
Print a list of all known users of the current server.
p4 verify
Verify that the server archives are intact.
p4 workspace
Create or edit a client workspace specification and its view.
Tagged : / / / / / / / / / /

Most User P4 Command Line – P4 Commands Reference

p4-command-line

p4 add

Open file(s) in a client workspace for addition to the depot.

Assigns a specific file type to a new file, overriding any settings in the typemap table

p4 add -t binary file.pdf

Opens all the files within the user’s current directory for add, and links these files to changelist 13.

p4 add -c 13 *

Opens all *.c files in the user’s ~/src directory for add; also opens the README file in the user’s current working

directory for add. These files are linked to the default changelist.

p4 add README ~/src/*.c

Opens a file named *.c for add.

p4 add -f *.c

p4 admin

Perform administrative operations on the server.

Stop the Perforce server

p4 admin stop

p4 change

Create or edit a changelist specification.

Create a new changelist.

p4 change

Edit previously submitted changelist 25. Administrator or superuser access is required.

p4 change -f 25

p4 changelists

List submitted and pending changelists.

p4 delete

Open file(s) in a client workspace for deletion from the depot.

Opens the file called README in the depot’s top level directory for deletion. The corresponding file within the client workspace is immediately deleted, but the file is not deleted from the depot until the default changelist is submitted.

p4 delete //depot/README

Opens file in the current client workspace for deletion. The file is immediately removed from the client orkspace, but won’t be deleted from the depot until changelist 40 is sent to the server with p4 submit.

p4 delete -c 40 file

p4 edit

Opens file(s) in a client workspace for edit.

Opens all files ending in .txt within the current directory’s doc subdirectory for edit. These files are linked to the default changelist; these files are stored as type text with keyword expansion.

p4 edit -t text+k doc/*.txt

p4 have

List files and revisions that have been synced to the client workspace

p4 info

Display information about the current client and server.

p4 integrate

Open files for branching or merging.

Branch or merge all files in //depot/dev/… to the corresponding files in

//depot/rel2/… If there is no corresponding file in //depot/rel2/…, this creates it.

p4 integ //depot/dev/… //depot/rel2/…

p4 job

Create or edit a defect, enhancement request, or other job specification.

p4 login

Log in to a Perforce server by obtaining a ticket.

p4 passwd

Change a user’s Perforce password on the server.

p4 resolve

Resolve conflicts between file revisions.

p4 revert

Discard changes made to open files.

Revert all open files to their pre-opened state.

p4 revert //depot/…

p4 submit

Send changes made to open files to the depot.

Submit the default changelist. The user’s revisions of the files in this changelist are stored in the depot.

p4 submit

Submit changelist 41.

p4 submit -c 41

p4 sync

Copy files from the depot into the workspace.

p4 sync

p4 sync file.c#4

p4 sync //depot/proj1/…@21

p4 user

Create or edit Perforce user specifications and preferences.

View the user specification of Perforce user joe.

p4 user joe

Edit the user specification for the current Perforce user.

p4 user

Delete the user specification for the Perforce user sammy.

p4 user -d sammy

P4CONFIG

Tagged : / / / / / / / / / / / /

Perforce Quick Facts – Perforce Quick Start Guide

perforce-quick-facts

Perforce Quick Facts

Clients
==============================================
P4V: Visual Client – (Included in the P4V Installer)
Provides access to versioned files through a graphical interface and also includes tools for merging and visualizing code evolution.
P4Merge: Visual Merge Tool – (Included in the P4V Installer)
Provides graphical three-way merging and side-by-side file comparisons
P4: Command-Line Client – (Included in the Perforce Server Windows Installer)
(Included in the Perforce Server Windows Installer)
P4Web: Web Client – (Included in the P4Web Installer)
Provides convenient access to versioned files through popular web browsers
Server
================================================
P4D: Server – (Included in the Perforce Server Windows Installer)
Stores and manages access to versioned files, tracks user operations and records all activity in a centralized database.
P4P: Proxy Server – (Included in the Perforce Server Windows Installer)
A self-maintaining proxy server that caches versioned files remotely on distributed networks.
Plug-ins & Integrations
=========================================
P4WSAD: Plug-in for Eclipse and WebSphere Studio
Access Perforce from within the Eclipse IDE and the Rational/WebSphere Studio WorkBench family of products
P4SCC: SCC Plug-in – (Included in the P4V Installer)
Enables you to perform Perforce operations from within IDEs that support the Microsoft SCC API including Visual Studio.
P4EXP: Plug-in for Windows Explorer – (Included in the P4V Installer)
Allows Windows users direct access to Perforce.
P4DTG: Defect Tracking Gateway – (Included in the P4DTG Installer)
Allows information to be shared between Perforce’s basic defect tracking system and external defect tracking systems.
P4GT: Plug-in for Graphical Tools
Provides seamless access to version control for files from within Adobe Photoshop, SoftImage XSI, Autodesk’s 3ds max, and Maya
P4OFC: Plug-in for Microsoft Office
Allows documents to be easily stored and managed in Perforce directly from Microsoft Word, Excel, PowerPoint and Project.

Tools & Utilities
=============================================
P4Report: Reporting System
Supports leading tools such as Crystal Reports, Microsoft Access, and Microsoft Excel, or any reporting tool that interfaces with an ODBC data source.
P4Thumb: Thumbnail Generator
Creates thumbnails of graphics files managed by Perforce and stores the thumbnails in the server for presentation in P4V.
P4FTP: FTP Plug-in
Allows FTP clients like Dreamweaver, Netscape, and Internet Explorer to access files in Perforce depots.’
Links to Download: http://www.perforce.com/perforce/downloads/platform.html

Tagged : / / / / / / / / / / / / / / / / /

“Cheat Sheet” of Perforce command-line | Perforce command-line Guide

perforce-command-line-cheatsheet

A way to remember data-mining commands
The following is a set of questions that will be used during the Perforce training to remind students which “data-mining” commands to use for specific situations. Perforce is a terrific tool, but it’s easy to get lost in the choices between “p4 files” and “p4 changes” and “p4 filelog” and so on. This list can help a great deal.

the question starts with…
the answer starts with…
Examples
“What are the filenames that…?” “p4 files….” p4 files //depot/…#have
p4 have
p4 files //depot/…
(which is the same as)
p4 files //depot/…#head
p4 files //depot/…@label
p4 files //depot/…@client
p4 files //depot/…@2001/02/12
p4 files //depot/…@1541
“What are the differences between the
workspace copy of XXX and the depot
copy of XXX?”
“p4 diff …” • p4 diff file.c
• p4 diff file.c#2
• p4 diff file.c#head
• p4 diff //… or “p4 diff”
• p4 diff –se
“What are the differences the depot copy
of ______ and the depot copy of ______?”
“p4 diff2 ….” • p4 diff2 file1.c file2.c
• p4 diff2 file1.c#1 file.c#2
• p4 diff2 dir1/… dir2/…
• p4 diff2 dir1/…@now dir1/…@2000/01/02
“Tell me everything about changelist #___.” “p4 describe” • p4 describe 1231
“What’s a list of changelists that….?” “p4 changes….” • p4 changes
(which is the same as)
p4 changes //…
• p4 changes file.c
• p4 changes –i file.c | grep 1255
• p4 changes //depot/…@label1,@label2

 

“Cheat Sheet” of Perforce command-line
The following list is a set of helpful commands that anyone can run, but that the person administering the Perforce codelines will
be using a lot. They’re included here for quick reference.

Function
Commands
Create a new workspace…
1. That’s modeled after the
“1.0dev” workspace – same
mappings
2. That’s the Perforce defaults,
Set the workspace name using “p4 set” or in the environment. Then run:
1. p4 client –t 1.0dev
2. p4 client
Retrieve a file as of
1. Now (head revision)
2. April 15, 2000
3. Label “xyz”
4. Changelist 123456
5. the revision that client
“jab.work” has retrieved
6. The revision you had before
accidently bashing your disk
Use “p4 sync” as follows:
1. p4 sync file.java
p4 sync file.java#head
p4 sync file.java@now
2. p4 sync file.java@2000/04/15
3. p4 sync file.java@xyz
4. p4 sync file.java@123456
5. p4 sync file.java@jab.work
6. p4 sync –f file.java#have
See “p4 help revisions” for more examples. Note that anywhere that “file.java” is used in these
examples, a full pathname (“c:\work\projects\file.java”) or depot name
(“//depot/rel_218/base/projects/file.java”) could be used.
Open a file for:
1. add
2. edit
3. delete
And then publish the change to others
.
Use “p4” with the appropriate verb:
• p4 add file.java
• p4 edit file.java
• p4 delete file.java
Then “p4 submit” to publish it
What have I changed in the files I
have opened for edit?
• p4 diff (for all opened files)
• p4 diff file1 file2 (for specific files)
Undo a checkout. If the file hasn’t been submitted yet:
• Use “p4 revert –a” to find all opened files that have no modifications – it’ll revert those.
• Use “p4 revert file.java” to revert an individual file.
• Use “p4 revert //…” to revert all files.
Remember that “p4 revert” is irreversible.
If the file has been submitted, you’ll need to open the file for edit and check in a prior revision.
Use very good change descriptions to say what you did and why.
Interrupt your work to edit a single
file and check it in, without any other
disruptions. (You’re hacking Java and
someone needs a “relnotes.txt”
updated ASAP to issue a release.)
Two ways:
1. Edit the file and submit only that file.
• p4 edit relnotes.txt
• do the modifications
• p4 submit relnotes.txt
2. Make a new changelist to manage just that change.
• p4 change
remove all the files in this change from the Files: section, it’ll create an empty
change.
• p4 edit –c XXX relnotes.txt
where XXX is the change number in the previous step
• p4 submit –c XXX
Publish your work to others “p4 submit”
Compress the data on the net
because you have a slow modem line
between your workspace and the
server.
Run “p4 client” for your workspace, and change the options from “nocompress” to “compress”.
(Read “p4 help client” for details.)
Get the list of…
1. All changelists applied to the
base codeline
2. … to the prodxyz codeline
3. … to the prodxyz codeline,
including those applied
originally to another codeline
and integrated into prodxyz
4. All revisions of file.java
Use “p4 changes” or “p4 filelog” as follows:
1. p4 changes //depot/eng/…
2. p4 changes //depot/eng/prodxyz/…
3. p4 changes –i //depot/eng/prodxyz/…
4. p4 filelog file.java
Push … from the base codeline
(“prodxyz”) to the 1.0.1 codeline
(“prodxyz-1.0.1”):
1. Push change #1232
2. From change #129 to #134
3. all changes in the base
codeline
Use “p4 integrate –b prodxyz-1.0.1” as the place to start, in each case:
1. p4 integ –b prodxyz-1.0.1 //…@=1232
2. p4 integ –b prodxyz-1.0.1 //…@129,@134
3. p4 integ –b prodxyz-1.0.1 (no additional args)
Note that this assumes that the named branch specification “prodxyz-1.0.1” has been created
by your project lead or administrator using “p4 branch”.
Push … from the prodxyz-1.0.1
codeline to the base (“prodxyz”)
codeline:
1. Push change #1235
2. From change #127 to #128
3. all changes in the base
Use “p4 integrate –b prodxyz-1.0.1” as the place to start, in each case:
1. p4 integ –b prodxyz-1.0.1 –r @=1235
2. p4 integ –b prodxyz-1.0.1 –r //…@127,@128
3. p4 integ –b prodxyz-1.0.1 –r (no additional args)
The “-r” reverses the order of source/target in that named branch specification.
Note that for the ‘selective integration’ cases, you’ll want to be VERY CAUTIOUS of ‘accept
theirs’.
Show the ‘diff’ between the
prodxyz-1.0.1 codeline and its
parent
“p4 diff2 –b prodxyz-1.0.1” (This works because “prodxyz” is the name of the branch
specification, not because “prodxyz” is part of “//depot/prodxyz/…”)
What branches do I have? If you use “p4 branch” to create branch specifications and use them consistently, then “p4
branches” provides this info.
How do I make a new codeline
named prodxyz-2.0?
There are several steps:
1. Make a named branch specification. Save it.
• “p4 prodxyz-2.0”
• if you want to exactly imitate another branch (e.g. prodxyz), use
“p4 branch –o prodxyz-1.0.1 > tmp” to capture the output, edit this temporary file
and replace the “1.0.1” references with “2.0”, then run “p4 branch –i < tmp”.
2. Run the “p4 integrate” command to populate this new codeline. Submit the change.
• p4 integrate –b prodxyz-2.0
or, if you want to push content as of a certain label (e.g. “xyz”) from the parent,
p4 integrate –b prodxyz-2.0 //…@xyz
• p4 submit
3. Send e-mail telling everyone about this codeline and what it’s used for.
Put everything onto a laptop, you’re
going to the beach and want to hack.
(This assumes that you won’t be
connected to a net while away.)
There are several steps:
1. Connect the laptop to the net.
2. Run “p4 sync” to populate the source onto the laptop.
3. Leave for the beach.
4. While editing, use “chmod” or “attrib” to make the files writeable. Make your changes.
5. Get back to work, reconnect to the net.
6. Run the following commands to tell you what’s updated and open them for
add/edit/delete:
• p4 diff –se | p4 –x – edit
• p4 diff –sd | p4 –x – delete
• find . –type f –print | p4 –x – add
Then inspect what’s opened (“p4 opened”) and what you’ve changed (“p4 diff”). Submit or
revert as appropriate.
Run a checkpoint “p4 admin checkpoint” – only an administrator can run this. (An administrator has “super”
permissions in the “p4 protect” data.)
Be sure to back up the checkpoint, the current journal, and each of the “depot” directories on
the server machine!
Change the security/permissions “p4 protect” – only an administrator can run this.
Also…
“p4 protects” – used in 2006.1 and later to TELL you your permissions .
Make a label It’s a two-step process:
1. Make the label using “p4 label xxx”
2. Populate it using “p4 labelsync –l xxx”
or if you have a specific list of files,
“p4 labelsync –l xxx file1 file2 …”.
Copy a label’s contents to another
label. Assume that the existing label
is “xxx” and the new label is to be
“abc”.
Again, a two-step process:
1. Make the label using “p4 label –t xxx abc”
2. Populate it using
“p4 labelsync –l abc //…@xxx”
Note that the second step is really identical to the second step in the previous question – we’re
just specifying a very specific list of revisions [of files] to include in the new label.
(Also…
In 2005.1 and later, “p4 tag” will make the label and apply it to a set of files.)

 

Tagged : / / / / / / / / / / / / / / / / / /

How to Write Trigger in Perforce? – Perforce Triggers Guide

trigger-in-perforce

1 Introduction
Perforce introduced the first server-side trigger in release 99.1 with the pre-submit trigger. This trigger satisfied a long-standing desire in the user community, but demand continued for more hooks. In release 2004.2, Perforce squarely hit the need with the addition of five new trigger types. Release 2005.1 adds yet one more trigger type to this list rounding out one of the categories of triggers to completeness. This paper discusses triggers, techniques for implementing them and purposes for using them. It presumes a general knowledge of scripting. The examples follow in several programming languages. They should be easy to follow with knowledge of general programming, and any more arcane constructs will be explained. The paper also presumes a reasonable knowledge of Perforce scripting alternatives, such as that presented in [Bowles2005]. Although this paper will address the scripting of triggers comprehensively, it will refer to other Perforce scripting contexts and to Perforce commands with an assumption of familiarity.

1.1 What is a trigger?
Triggers are programs that run on the server immediately in response to some welldefined event in Perforce. Therefore, the context for a trigger is running on the server
using the trigger mechanism to start. Triggers are typically written in a shell script such as Perl, Python or Ruby due to the flexibility and facilities they provide. However, triggers can be written in any programming language that can interface with Perforce, including UNIX shell (sh, ksh, csh and work-alikes) and compiled languages like C/C++.

1.2 Types of triggers
Triggers fall into two categories. Pre-submit triggers enable actions in response to the submission of changelists. Form triggers allow actions in response to various stages of the life cycle of a form, regardless of the form type. This section provides a brief overview of the trigger types in preparation for the more detailed discussion.
1.2.1 Pre-submit triggers
There are three types of pre-submit triggers corresponding to different points in the life cycle of a submission.
• “Submit” triggers execute after the changelist has been created but before the files have been transferred, allowing inspection of the changelist details but disallowing file inspection.
• “Content” triggers execute after file transfer but before commit, allowing for inspection of the files.
• “Commit” triggers execute after the commit, allowing inspection of the changelist and file contents, but disallowing canceling of the submission.

1.2.2 Form triggers
Form triggers come in four types depending on the point in the form’s life cycle in which they are invoked.
• “Out” triggers execute when the form is generated and can modify the form before it is presented to the user.
• “In” triggers execute when the form is sent back to Perforce but before it is parsed, also allowing modification of the form on its way in.
• “Save” triggers execute after the form has been parsed but before it is saved, allowing reaction to the form but not modification.
• “Delete” triggers execute before a form is deleted, allowing failure of the deletion.

1.3 Why use a trigger?
Knowing why to use a trigger is partially a matter of knowing what are the competing alternatives. The alternatives naturally come from other contexts, since triggers define a context of their own. This section details the salient operational characteristics of triggers and contrasts them with Perforce alternatives. The three primary alternatives to triggers are wrapper scripts, such as p4wrapper, 1 review daemons, and journal tailers. A variation on the wrapper script would be a script available from the Tools menu in P4Win.

1.3.1 Synchronous execution
Triggers execute synchronously in response to their associated event. This provides an immediacy of response that is sometimes required or at least highly desirable. One option that provides synchronous execution could be an action invoked from a wrapper script such as p4wrapper. Another option would be to forego synchronous execution and rely on frequently running review daemons. Journal tailers would also perform asynchronously, although with very rapid and event-driven response.
1.3.2 Immediate user feedback on error
Triggers can provide messages back to the user, but only on error. Messages are not delivered on successful execution. A wrapper script can deliver messages to the user regardless of whether an error occurs or not. Review daemons and journal tailers can only provide feedback through indirect mechanisms.
1.3.3 Enforceability
Enforceability refers to the ability of an administrator to ensure that the script will run regardless of the client program used to initiate the operation. Because triggers are
installed on and executed by the server in response to server events, they will execute regardless of the client program. Wrapper scripts will only be invoked when the wrapper is used, whereas direct use of p4 or use of a different client program will circumvent the desired action. Review daemons and journal tailers are also enforceable due to their context on the server.

1.3.4 Modify a form
Form triggers can modify a form as it is delivered to the user or as it is sent back to Perforce. Wrapper scripts share this characteristic. Review daemons and journal tailers can not modify forms except to the extent that any user or administrator can after the operation has finished.
1.3.5 Customize any action
Form triggers have a limited ability to customize actions that involve forms, but they do not have the ability to react to any arbitrary command. Similarly, pre-submit triggers can only react to submits. Review daemons can only react to commands whose side effects can be reliably observed, something that is not readily available from the command line in many cases or from review mechanisms. Journal tailers have the ability to react to any action that affects database entries, which includes almost all.
1.3.6 Optimization for bulk processing
The review mechanism gives the ability to process a large number of actions in an orderly and efficient manner as long as those changes impact a counter. This optimization is not readily if at all available to triggers, wrappers or journal tailers due to their association with individual commands or journal entries.

1.3.7 Deterministic execution
Triggers and wrappers provide an exact and deterministic understanding of when they will execute relative to the command that initiates them. Review daemons are generally driven in a time-based manner and therefore do not execute deterministically relative to the Perforce command. Journal tailers are closer to deterministic than review daemons, but can conceivably execute prior to completion of a command.
1.3.8 Summary
The following table summarizes the characteristics of the scripting contexts that compete with triggers for Perforce scripting.

 

Tagged : / / / / / / / / / / / / / / / / / /

Command Line to find a Change list properties in perforce server

command-line-to-find-a-change-list-properties-in-perforce-server

Command Line to find a Change list properties and associated path of the file in perforce server view:

Examples of the command you want:
p4 describe 1231928
p4 describe -s 1231928
p4 files @=1231928

Where 1231928 is the change list number.

Tagged : / / / / / / / / / / / / /

Step by step guide on PerforceDFiles Tool | Perforce Tutorial

perforcedfiles-tool

PerforceDFiles
Use:
This tool can be used to add thousands of files and directory in perforce server on single click which is having different-different hierarchy

Prerequisite:
Java should install and class path should set.

Step1:
Put the code under ClientSpec root folder in the same hierarchy which you want to add in perforce server.

Step2:
Create a changelist first. Just go to command prompt and type “p4 change”. Perforce will automatically create a changelist and will give you the changelist number. It will also ask you to update a text file with the changelist description. Just give the appropriate description there. Note the changelist number.

Step3:

The file file has one file called “config.properties”. So first update it with two values. The changelist number and the source path. The source path can be “D:/Perforce/Components/DatabaseServer”.
Use forward slash only “/”.

Step4: Once these files are updated, you can run the script file “makescript.bat” which will update the “checkinscripts.bat” with new checkin scripts.

Step5: Run “checkinscripts.bat” and refresh perforce console. See that new folder is created below components folder and the files are inside

Note: The file which will not be added into perforce server can be found in “missedfiles.log”

 

Links: http://www.scmgalaxy.com/index.php?option=com_docman&Itemid=110

Tagged : / / / / / / / / / / /

The P4Win Window Navigation | P4Win Navigation Guide

p4win-window-navigation

The P4Win Screen 

The P4Win screen resembles the Windows Explorer. The following diagram points out the main portions of the screen. Each pane is described in detail in the following sections.  

The Depot Pane

Depot contents are displayed in a tree in the left pane.

Picture DepotPane:

Some navigation hints:

Multiple selections: Shift-click to select contiguous items, Ctrl-click to select noncontiguousitems.

Select next/previous: Up and down arrows traverse the current level, and right and leftarrows move the cursor up and down through the folder hierarchy.

Open a selected folder: Use the asterisk (*) key on the numeric keypad.You can control which files are displayed in the depot pane. For example, you might want to restrict the list of files to display only the files for the project you’re working on, or conversely, you might want to see every file in every depot. The scope is controlled by your client specification and the view you choose for the depot pane.

The Right PaneThe right pane displays changelists, jobs, client specifications, users, labels or branch specifications. To change the display, click the corresponding toolbar button.  

The ToolbarThe P4Win toolbar contains buttons that provide shortcuts for common P4Winoperations. However, there’s a menu equivalent for every button on the toolbar. Note that buttons are gray if an operation is not available. For example, some operations require you to select a file first. If no file is selected, the button (and the corresponding menu item)are gray. Here’s what the buttons do: 

 

The Status PaneIn the status pane at the bottom of the screen, P4Win displays the commands it sends to the Perforce server, the results of operations, and, for some P4Win operations, lists ofinformation.  

P4Win FormsTo define changelists, users, workspaces, labels, jobs, and branches, you enter information into forms displayed by P4Win. For example, the following figure shows the changelistform.  

Tagged : / / / / / / / / / / / /