( Last Modified: 2008 October 16th 01:54 PM)
There seem to be a number of these "Why Perforce Sucks" compositions on the net, here is my contribution.
The paradigm of "In perforce you tell the server you are going to make a change." before you make it, rather than make changes first.
I find this makes developmeny much slower than with other SCMs that don't use this paradigm.
One workaround is to open everything for edit and set the SubmitOptions clientspec variable to "leaveunchanged+reopen". Rather then open one file at a time for edit as needed.
Possible to use P4Win > File > More > Check Consistency, with allwrite, so you don't have to tell perforce what files you have changed, but working around all perforce speed/efficiency.
This is intended to serve a purpose though. Because edits must be told to perforce to make files writable. You can see who has what files open, and share status between developers.
It currently seems the best way to do this if to drag and drop an entire folder into a changelist P4win and see what appears and revert the rest.
This assumes you have all client spec up to date to ignore all the temporary files in you workspace, or you'll have to sift though them each time.
- You can ignore locations in client specs, but cannot check these into the repository
- .p4ignore only works for p4wsad?
- Related to "No easy way to find files to add." because if you get perforce to search for new files you need to ignore locations that will always have new files that you aren't interested in.
Possible work around allwrite option can cause data loss (clobbering).
"What I have seen is that if you check out with allwrite and even if you have
noclobber option set p4 will overwrite your files."
- http://maillist.perforce.com/pipermail/perforce-user/2003-March/010679.html
A common shortfall of SCMs
And set for all files in client, can exclude makefiles etc...
Specifies which line-ending convention is used when a file is synced to the client workspace.
LOCAL: Uses the client platform default
UNIX: LF
MAC: CR
WIN: CR LF
SHARE: Line endings are LF. Any CR prior to a line ending is removed for storage or syncing (for disks shared between UNIX and Windows)
