I am trying to automatize some tasks of MKS Integrity via command line. Since we are forced to use the change package feature, I try to get a list of all change packages of a single MKS project. How can this be achieved?
I already checked the command line references of 'si' and 'im', but I still have no idea how to get such a list. The only thing I already got to work was a list of change packages from 'si rlog'. Here I could parse the output and drop all duplicate entries. But the problem is, that I only get change packages from files, currently available in the project. Change packages affecting deleted files are not included.
To look up change packages by project use the following command:
si viewcps --filter=project:"c:/path_to_project/project.pj"
Note that the slashes are forward, not backwards like Windows uses.
There are also different fields and formats available, not just the default ones. if you run man "si viewcps" at the command prompt, it will give you a list of fields you can use with the optional --fields tag to output additional information.
Output can be modified to limit results to CP type, state, target, etc. man "si viewcps" gives details on how to use these options as well.
Related
Is it possible to have vscode automatically open the newest folder within a specific path?
For example, with this configuration:
{
"folders": [
{
"path": "\\\\FromABC\\Archive",
"name":"From ABC"
},
{
"path": "\\\\FromXYZ\\Archive",
"name":"From XYZ"
}
]
}
I would expect these folders in the workspace to be pointing to \07\07 because those were created today:
\\\\FromABC\\Archive\\2021\\07\\07
\\\\FromXYZ\\Archive\\2021\\07\\07
Is it possible to create a workspace where the folders are opened to the latest folder within each configured path?
There's not enough information in the original question to fully answer it, however, I can suggest a few avenues of attack
Custom Command (error-prone and picky)
Modify Upstream Process (likely the best overall)
Combining Both (perhaps the best for your immediate case)
Creating a Custom Command
Create a new command per https://code.visualstudio.com/api/extension-guides/command#creating-new-commands
VSCode Commands Listing: https://code.visualstudio.com/api/references/commands
new command
detect latest folder through whatever logic you like
call vscode.openFolder to navigate to it
call your custom command through Activation Events (activationEvents) at either onStartupFinished or * (Start Up; less-preferable, but may be required to avoid confusing the editor)
https://code.visualstudio.com/api/references/activation-events#Start-up
Check out Start app when opening project in VS Code? for a few answers related to this
Modifying the Upstream Process
Cutting the gordian knot, it's likely some process (perhaps a human) is creating the directories for you
Change the upstream process so when it creates the directories, it also creates/updates a link to the directory labeled something like latest
/FromABC/Archive/2021/06/03
/FromABC/Archive/2021/07/05
/FromABC/Archive/2021/07/07
/FromABC/Archive/latest --> /FromABC/Archive/2021/07/07
/FromXYZ/Archive/2020/04/12
/FromXYZ/Archive/2021/08/18
/FromXYZ/Archive/latest --> /FromXYZ/Archive/2021/08/18
Then you can always refer to the latest directory and it will always be correct
This is quite common when something can change frequently, but another process is expecting a static path and/or has no way to know the schedule of change
I don't have any Windows systems to try this out with and you may be able to create a regular shortcut for this .. however, you may need a Junction (soft-link) or Hard Link to convince VSCode that the directory is a real directory
https://learn.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions
This also provides an opportunity to include more files, such a beta versions of some software, which it's desirable to package into the same directory structure, but not truly the latest stable!
Combining Both
If your upstream process is either not modifiable (or some manual process it's annoying or error-prone to add extras steps to) you can likely combine both solutions to get what you really want
Use the * Action Event to call a script to detect and create the new directory - create a binary or PowerShell script to make your link
In this and with the upstream change, just point VS Code to the latest directory and it shouldn't mind
Not sure on which platform you are, I assume windows, but essentially similar.
Instead of trying to get VSCode to open the latest folder, I would create a script that updates a softlink for each folder to the latest subfolder in it. Then you can point VSCode to the softlink, which can be updated whenever needed to the latest subfolders.
What are the recommended steps to upgrade TYPO3 4.5 (or 6.1) to 6.2? I have a mac and my site is running on a shared Linux account.
Here's a step by step guide from my upgrading practice which I would like to share. Thanks for the guide on https://jweiland.net/typo3/vortraege/typo3camp-berlin-2014.html that has helped me a lot.
Note that these are my personal experiences which may or may not apply to your environment. Treat everything carefully.
I differentiate between "Quick" and "Long" upgrades. With "Long" upgrades, you do the upgrading twice. First, you upgrade a copy of the live site, get all extensions and templates working, and when you're ready, you declare the content freeze, re-doing the upgrade, using the files modified in the first step. For a "Quick" upgrade, you declare a content freeze right away, do the upgrade and tests, and then deploy to the test or live environment directly.
Set up the site locally
When you're ready to freeze the content (BE][adminOnly] = 0), don't forget to check if the site has user contributed content? If so, either disable the possibility to submit it, or note which tables you have to re-import after enabling the upgraded site.
Hint:
Work locally. I can only refer to using MAMP Pro (be sure to get the
pro version) on a mac. Always be aware on which site (and with which
DB) you are working, btw! And attention: OS X file system is case
insensitve, which can be a bummer when deploying to Linux (see below).
For the database administration, I prefer http://www.sequelpro.com/ to
phpMyAdmin for most tasks. It's very handy to make backups or to
quickly browse tables, although it has a few missing features in
comparison with phpMyAdmin. It is also extremely reliable for
importing dbs onto a live server - where phpMyAdmin can stall often.
Beware if [SYS][UTF8filesystem] is set: transferring files to OS X via popular (S)FTP clients like Coda or Transmit (haven't tested Cyberduck) can damage the filenames containing UTF-8 filenames. Thus all links to such files will be invalid when you deploy. Pack them into an archive befor transferring or use scp. Avoid the setting in the first place.
Create your local TYPO3 instance. It's practical if you keep an "old" and a "new" core in the same location, so you can switch between them easily by symlink. Create and connect the local database.
Hint:
If you're working on MAMP, you'll have to chown all the files (except
templates and config files of your apps (like Sublime)) to _www:_www.
I have found it useful to define some aliases for the sudo chown in
~/.bash_profile, like alias chownmamp="sudo chown -R _www:_www ."
and vice versa to your own user. Another possibility might be to
temporarily chmod 777 everything - when deploying, taking extra care
this is removed (find . -type f -exec chmod 644 {} \;find . -type d -exec chmod 755 {} \;)
Duplicate the site and the DB to keep an un-upgraded version for comparison - even after you've deployed
Init a local git repo, don't forget to add .gitignore for temp data. Commit from time to time!
Hint:
If you use different hostnames for your local and the live site,
replace them where needed. For the command line, I have found grep -rl 'www.site.ch' ./ | xargs sed -i 's/www.site.ch/www.localsite.dev/g' useful. But of course you can
do that in your IDE or editor too. Don't forget to check
realurl_conf.php and .htaccess too. For a quick run, it is also
possible to use the real hostnames, so you don't have to replace
anything (but won't be able to compare sites from the same machine).
You should now be able to log into the backend and into the install tool
Hint: On MAMP, I've had issues with $TYPO3_CONF_VARS['BE']['warning_email_addr'] which prevented logging into the install tool with an error 500, as it couldn't sent the email. Remove that setting in localconf.php for the local upgrade if it happens.
Prep the upgrade
Make a backup of files and DB. (make frequent db dumps later on too)
Important: Install tool > Database Analyser > Clear Tables: clear all caches, logs, also the history data (if that's ok with you). The less huge the database is, the smoother the upgrade will go.
Get the frontend running.
Also, make sure you have the admin Panel. It's very helpful to override TYPO3 caching and to debug performance bottlenecks. Also, you can reliably force TS rendering at every reload. Set config.admPanel = 1 in page TS, enable it in your admin user's TS by admPanel=1, and log in with the domain you will be viewing the FE from. The adminPanel only shows up if you're logged in on that domain! While you're there, also add options.clearCache.system = 1 to the admin's TS, so you can clear the system cache also when in production mode.
Install http://typo3.org/extensions/repository/view/smoothmigration and run it. Fix the issues you can fix now, e.g. UTF8 issues in the DB. Copy the remaining report and save it in a word file or similar - you can't run smoothmigration after the upgrade anymore
Go through all extensions. Do we need them at all? You can find out if a plugin is used with (for example) SELECT * FROM tt_content WHERE list_type = 'news_pi1' or by looking at all cType = 'list' entries in tt_content. If it's not used, consider removing the extension too. Or can it be replaced by a better extension, or re-built by hand / via tt_content? (For example a carousel, I'd rather not have to maintain an extension for that. But check the budget! Everything takes time.
I get rid of indexed_search, as ke_search is a very reliable alternative that is quick to set up.
Hint: with FAL, the _cli_scheduler user needs rights for every file mount you want to index with ke_search, else the indexing via scheduler will fail.
Main task: Check for extension updates. If a compatible extension update is available, do it. But first check if it works with the old and the new site: http://typo3.org/extensions/repository/view/realurl : This version works for TYPO3 4.5.0 - 6.2.999 - if it doesn't, don't update yet.
Be sure to remove realurl_clearcache, the TER version will break on 6.2
When you're done removing, uninstall all remaining local extensions. You don't have to uninstall sysexts.
in typo3conf/ext we will have a quite short list of extensions now. That is good!
Backup the db and make a DB-Compare in the install tool. CAUTION: don't touch extension data you will need for importing later on (tt_news, powermail, dam). If you dare, you can rename or remove other, 100% obsolete data.
Study the "Reports" module in the BE and take the recommended actions
If you have the patience, check for broken links on the site - they may make problems when converting to FAL.
Is there content / pages that can be deleted for sure? (E.g. ancient test pages, duplicates, etc?) Delete it if you dare.
Don't forget: Empty the trash (Module "Trash") for all pages recursively. No need to migrate deleted content. Cf. https://forge.typo3.org/issues/62360 to delete many items at once
Important: Update the reference index (in the module "DB Check"). It has to be PERFECT before the upgrade.
Make that backup...again
Do the upgrade
-> Switch the core to 6.2
Reload the backend, you will land in the install tool. To connect to the DB, you may have to enter "localhost" instead of 127.0.0.1 as prefilled
Install tool: check folder structure and system environment, make it all green. Read System Environment until the bottom: "Red" items are on the top, but "blue" items (recommended) are on the bottom (e.g. a missing system locale, which is needed if you use UTF8-Filesystem).
Hint: don't be too eager with APC, the availability check
in 6.2 isn't perfect, cf. https://forge.typo3.org/issues/64030 (you
can't use it if your shared hosting relies on suPHP).
Install tool: Run the first wizard. Just the first one. Do NOT run "Migrate all file links of RTE-enabled fields to FAL" yet.
Important: Log into the backend as admin. Go to filelist, refresh the file tree if necessary. Now set the filemounts (fileadmin...) to "Use case sensitive identifiers" in it's settings. Otherwise, you may end up with all filenames in lowercase in sys_file, which will not work on the live linux system.
Also, run the task File Abstraction Layer: Update storage indexin the scheduler and update the reference index.
Install tool: Go through the rest of the upgrade Wizards. To debug broken links that can't be migrated, use the workaround from https://forge.typo3.org/issues/64122 (6.2.10 up)
Hint: If something doesn't seem to be complete after all wizards went through, you can re-enable the upgrade wizards in LocalConfiguration.php under ['INSTALL']['wizardDone']. (Like if the whole sys_file_reference table empty and there are no images in tt_content table - remove the line for TceformsUpdateWizard, so it can run again).
Important: Install tool: All Configuration: Deactivate content adapter! Else you will be running in a slow kind of compatibility mode and not really doing the entire Upgrade.
Check "Reports". Make it all green!
Install tool: Check image rendering (I prefer GD), set fitting Configuration presets
Hint: Check typo3conf/AdditionalConfiguration.php and make sure there are no values in it that override values from LocalConfiguration.php. I've had this on a 6.1->6.2 upgrade, and thus was unable to enable error logs (the devIPmask was overridden all the time).
Main task: Update and install Extensions that have updates that were not compatible with the old core.
Hint: here are a few occasional replacements I had to make
for 6.2 compatibility:
require_once(PATH_tslib . 'class.tslib_pibase.php‘);
-> if (!class_exists('tslib_pibase')) require_once(PATH_tslib . 'class.tslib_pibase.php');
require_once(PATH_t3lib . 'class.t3lib_scbase.php‘);
-> require_once(\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::extPath('backend'). 'Classes/Module/BaseScriptClass.php‘);
t3lib_div::GPvar()
-> \TYPO3\CMS\Core\Utility\GeneralUtility::_GP()
mysql_num_rows($res)
-> GLOBALS['TYPO3_DB']->sql_num_rows($res)
t3lib_div::intInRange
-> t3lib_utility_Math::forceIntegerInRange
t3lib_div::view_array()
-> t3lib_utility_Debug::viewArray
t3lib_div::testInt
-> t3lib_utility_Math::canBeInterpretedAsInteger
EDIT: a much more comprehensive list is on https://github.com/FriendsOfTYPO3/compatibility6/blob/master/Migrations/Code/ClassAliasMap.php
Updating from DAM? Use https://github.com/b13/t3ext-dam_falmigration, following Installation and Scheduler Task and Usage. Be aware that with MAMP, you have to run MAMPs PHP from the command line, for example /Applications/MAMP/bin/php/php5.5.18/bin/php ./typo3/cli_dispatch.phpsh extbase help
Moving tt_news to tx_news? I've had an issue with the importer where not all translations were imported. There is a newer version now.
Updating Powermail? Nice, there is an updater! Thanks! I also encountered issues with translations. In one case, they could be solved by hitting the "localise" button for a form, though.
rlmp_tmplselector: either use https://github.com/jweiland-net/rlmp_tmplselector/ or move page type seletion to core's backend layout.
Hint: In the last case, take care, to select the page template in
accordance to the selected BE Layout, never use .if, always use CASE.
See With TYPO3 be_layout, how to choose frontend template correctly (performance-wise)?
Main Task: Templates have to be updated. Just a few things: New IMAGE / FILES TS, config.doctype=html5 (not html_5), replace all HTML Objects by TEXT. Use the TypoScript Object Browser (TSOB) at least check that there are no errors in TS.
If you haven't done it before ("Long" Upgrade), install extension after extension and fix what has to be fixed (google the errors). Install https://github.com/medialis/realurl_clearcache by hand if you need it.
Do you use imagemap_wizard? https://github.com/lorenzulrich/imagemap_wizard and add the css fix from https://forge.typo3.org/issues/58212
Hint:
Btw, extensions I use on all sites: realurl_clearcache,
nc_staticfilecache, sourceopt, ke_search. On most sites
(feature-based), of course: news, powermail.
Don't forget: Check the backend permissions of non-admin users. It may be necessary to add rights for the tables and fields of the FAL (File Abstraction Layer). If you have to modify content, use a simulated editor user to spot problems early.
Update Translations via the "Language" Module, so editors will get translated Backend and Extensions
Hint: Also make sure that the "page tree rights" group is properly set
up, cf http://typo3.uni-koeln.de/typo3-admin-access-default.html?&L=0
There may be problems with filenames containing special characters like umlauts, sometimes resulting in broken file links (I use Integrity or Scrutiny for mac to check the whole site), sometimes only in ugly filenames. Check and process manually (if FAL works, you can just rename them in the backend) if required.
Hint:
Here's a snippet I add to all user's userTSConfig.
Go through everything. If you have the time and budget, make the website better, use webpagetest.org to spot performance holes, clean the .htaccess, combine assets, check the page rendering times in the admin tool, update frontend dependencies, check 404 handling, move templates to typo3conf/ext/templates (best search-replace all paths in a dump of the db!), tidy up users and groups, move all templates from db to includes, clean up template structure etc etc - it all depends on the time you have available for that site.
Make the backup. Again.
Test and deploy
Test it on a live server! Or, if it's not a high profile site that can afford some downtime, just go live, moving files (without typo3temp) and db to the server, setting the symlinks, clearing all caches etc.
On the live system, check the install tool. Probably you'll have to adapt some php.ini settings. And set the configuration preset to "Production".
Rebuild the reference index
Check "Reports". Regarding the case sensitivity issue, you might now see missing references here - you haven't seen those on the Mac, as you the file system was case insensitive. Also, you can query sys_file for missing = 1. You could re-run the scheduler FAL task mentionned above locally to see it can fix some filenames. If there are no other means, you could still rename all files to lowercase, cf. How do I rename all files to lowercase?
Check the cronjobs and scheduler tasks (go to "Check configuration" in the scheduler module as well, see if cli user exists). Ah, also see if you're running a current php version. Also check if you don't forbid google to crawl the live version in robots.txt
Do you have to configure some backup routines or update scripts? Do it now.
And don't panic if it's not working yet. Probably it's just the cache. Or something else.
When the site has been running to satisfaction for some time, run another dbcomp and delete all old tables.
Wait. What did I forget? Will add that later.
Check the backend permissions of non-admin users. It may be necessary to add rights for the tables and fields of the FAL (File Abstraction Layer).
I have a custom screen step displaying checkbox options for web.config specific to each environments (DEVINT, QA, Stage,Prod) as part of MSI installation.
Once the user selects QA as option then the web.qa.config file is renamed to web.config file
After the complete installation, I see that there are other web.config files ( web.DEVINT.config,web.stage.config,web.prod.config) still present in the folder.
I want to remove the other web.config files web.DEVINT.config,web.stage.config,web.prod.config
after the installation is completed.
Can anyone help me to resolve this issue.
Thanks & Regards,
Santosh Kumar Patro
A RadioBox would seem a better choice then a Checkbox since I would imagine the choices are mutually exclusive. Use the property associated with the control as conditions on the component so that only one of them gets installed.
Windows Installer will complain (ICE Valication) if multiple components install the same key path. What I do to get around this is to make the keys paths go to a subdirectory such as Configs\Web.LifeCycle.Config so that each is unique. Then I use the DuplicateFile table to clone that file to the real directory \ web.config path. The downside is I deploy a subdirectory/file that isn't needed but the upside is I can use it to quickly know what was picked and have a backup of the file to compare against in case someone goes and modifies the real web.config.
In limited scenarios I use AppSearch to autodetect the life cycle instead of showing a UI at all.
I'm interested in displaying the version number of my code in a help page. Ideally I'd use a Major.Minor.SVNrevision format, where the SVNrevision number was pulled automatically. I hope? Suspect there's a variable I can access somewhere, but have no idea what it may be.
Any hints?
You can do this by adding so-called SVN Keywords into your working files. This chapter contains standard SVN keywords. Then you have two options:
set property for each folder svn:keywords to make this substitution available for all who works with this repository: svn propset svn:keywords "Date Author Revision" help.html
modify svn configuration file (on Windows: %USERPROFILE%\Application Data\Subversion\config, on Linux: ~/.subversion/config) to enable automatic properties for all repositories and files (according to pattern) you're working with: set enable-auto-props to yes and then add to [auto-props] section: *.html = svn:keywords=Date Author Revision
If your help files are versioned, I would add an external script as an Eclipse builder in order to make some keyword substitution (using for instance svnversion)
But if your help files are generated, may be this kind of script can help (also based on svnversion to get back the "GlobalRev").
Major and Minor version information need to be stored and retrieved from another souce though: they are not "svn-related" informations.
I sometimes use the feature 'Reconcile Offline Work...' found in Perforce's P4V IDE to sync up any files that I have been working on while disconnected from the P4 depot. It launches another window that performs a 'Folder Diff'.
I have files I never want to check in to source control (like ones found in bin folder such as DLLs, code generated output, etc.) Is there a way to filter those files/folders out from appearing as "new" that might be added. They tend to clutter up the list of files that I am actually interested in. Does P4 have the equivalent of Subversion's 'ignore file' feature?
As of version 2012.1, Perforce supports the P4IGNORE environment variable. I updated my answer to this question about ignoring directories with an explanation of how it works. Then I noticed this answer, which is now superfluous I guess.
Assuming you have a client named "CLIENT", a directory named "foo" (located at your project root), and you wish to ignore all .dll files in that directory tree, you can add the following lines to your workspace view to accomplish this:
-//depot/foo/*.dll //CLIENT/foo/*.dll
-//depot/foo/.../*.dll //CLIENT/foo/.../*.dll
The first line removes them from the directory "foo" and the second line removes them from all sub directories. Now, when you 'Reconcile Offline Work...', all the .dll files will be moved into "Excluded Files" folders at the bottom of the folder diff display. They will be out of your way, but can still view and manipulate them if you really need to.
You can also do it another way, which will reduce your "Excluded Files" folder to just one, but you won't be able to manipulate any of the files it contains because the path will be corrupt (but if you just want them out of your way, it doesn't matter).
-//depot/foo.../*.dll //CLIENT/foo.../*.dll
Yes, But.
Perforce version 2012.1 added a feature known as p4ignore, inspired by Git. However the Perforce developers made a change to the behaviour, without justification, that happens to make the feature a lot less useful.
Whilst Git takes rules from all .gitignore files, Perforce doesn't know where to look until you specify a filename in an environment variable P4IGNORE. This freedom is a curse. You can't hack on two repositories that use different names for their ignore files.
Also, Perforce's ignore feature doesn't work out the box. You can set it up easily enough for yourself, but others don't benefit unless they explicitly opt-in. A contributor who hasn't may accidentally commit unwelcome files (eg. a bin folder created by a build script).
Git's ignore feature is great because it works out the box. If the .gitignore files are added to the repository (everyone does this), they'll work out the box for everyone. No-one will accidentally publish their private key.
Amusingly, the Perforce docs shows '.p4ignore' as an example ignore rule, which is backwards! If the rules are useful, they should be shared as part of the repository.
Perforce could still make good on the feature. Choose a convention for the file names, say p4ignore.txt, so the feature works out the box. Drop the P4IGNORE environment variable, it's counterproductive. Edit the docs, to encourage developers to share useful rules. Let users write personal rules in a file in their home folder, as Git does.
If you know anyone at Perforce, please email them this post.
This works as of Perforce 2013.1, the new P4IGNORE mechanism was first added in release, 2012.1, described on the Perforce blog here:
https://www.perforce.com/blog/new-20121-p4ignore
As it's currently described, you set an environment variable "P4IGNORE" to a filename which contains a list of the files to ignore.
So you can check it out to see how you like it.
If you want a solution that will apply to all work-spaces without needing to be copied around, you (or your sysadmin) can refuse submission of those file-types through using lines like the below in the p4 protect table:
write user * * -//.../*.suo
write user * * -//.../*.obj
write user * * -//.../*.ccscc
I remember doing this before, but I don't have the necessary permissions to test this here. Check out Perforce's Sysadmin guide and try it out
Perforce Streams makes ignoring files much easier, as of version 2011.1. According to the documentation, you can ignore certain extensions or certain paths in your directory.
From p4 help stream
Ignored: Optional; a list of file or directory names to be ignored in
client views. For example:
/tmp # ignores files named 'tmp'
/tmp/... # ignores dirs named 'tmp'
.tmp # ignores file names ending in '.tmp'
Lines in the Ignored field may appear in any order. Ignored
names are inherited by child stream client views.
This essentially does what #raven's answer specifies, but is done easier with streams, as it automatically propagates to every work-space using that stream. It also applies to any streams inheriting from the stream in which you specify the ignore types.
You can edit the stream via p4 stream //stream_depot/stream_name or right-clicking the stream in p4v's stream view.
And as #svec noted, the ability to specify ignore files per workspace is coming soon, and is in fact in P4 2012.1 beta.
Will's suggestion of using .p4ignore only seems to work with the WebSphere Studio (P4WSAD) plugin. I just tried it on my local windows box and any files and directories that I listed were not ignored.
Raven's suggestion of modifying your client spec is the correct way under Perforce. Proper organization of your code/data/executables and generated output files will make the process of excluding files from being checked in much easier.
As a more draconian approach, you can always write a submit trigger which will reject submission of change-lists if they contain a certain file or files with a certain extension, etc.
HISTORICAL ANSWER - no longer correct. At the time this was written originally it was true;
You can not write and check in a file that the server will use to make ignore rules; general glob or regexp file pattern ignore in perforce.
Other answers have global server configurations that are global (and not per folder).
The other answers show things that might work for you, if you want one line in your view per folder times number of extensions you want to ignore in that single folder, or that provide this capability in WebSphere Studio plugins only, or provide capability for server administrators, but not available to users.
In short, I find Perforce really weak in this area. While I appreciate that those who use the Eclipse Plugin can use .p4ignore, and I think that's great, it leaves those of us that don't, out in the dark.
UPDATE: See accepted answer for new P4IGNORE capability added mid-2012.
I have found it easiest to reconcile offline work using a BASH script like this one:
#!/bin/bash
# reconcile P4 offline work, assuming P4CLIENT is set
if [ -z "$P4CLIENT" ] ; then echo "P4CLIENT is not set"; exit 1; fi
unset PWD # confuses P4 on Windows/CYGWIN
# delete filew that are no longer present
p4 diff -sd ... | p4 -x - delete
# checkout files that have been changed.
# I don't run this step. Instead I just checkout everything,
# then revert unchanged files before committing.
p4 diff -se ... | pr -x - edit
# Add new files, ignoring subversion info, EMACS backups, log files
# Filter output to see only added files and real errors
find . -type f \
| grep -v -E '(\.svn)|(/build.*/)|(/\.settings)|~|#|(\.log)' \
| p4 -x - add \
| grep -v -E '(currently opened for add)|(existing file)|(already opened for edit)'
I adapted this from this Perforce Knowledge Base article.
I'm looking for a .p4ignore like solution as well (and not one tied to a particular IDE). Thus far, the closest thing I've found is p4delta. It sounds like it will do exactly what the original poster was asking, albeit through another layer of indirection.
http://p4delta.sourceforge.net
Unfortunately, while this does seem to produce the proper list of files, I can't get "p4delta --execute" to work ("Can't modify a frozen string") and the project has not been updated in year. Perhaps others will have better luck.
If you are using the Eclipse Perforce plugin, then the plugin documentation lists several ways to ignore files.