Talk:Perforce Helix

message: Mmm... AlienBrain is claiming that EA is one of their clients... Weird... -- lucasbfr talk 15:55, 19 December 2006 (UTC)
replies: text: ok I double checked. It seems EA dropped AlienBrain for Perforce. -- lucasbfr talk 15:59, 19 December 2006 (UTC)
thread_title:  Electronics Arts? 

message: I've removed the unsourced tags as I see three references in the 'Notes' section. If you disagree, please replace the tag and indicate here on the talk page which specific statements you feel are not adequately sourced so that this can be addressed. Thanks!
Zero sharp 19:36, 29 June 2007 (UTC)
thread_title: Unsourced?

message: I am reviewing Perforce for my company and as such the weakness section was very interesting to me.  I contacted Perforce support to get their responses to the items which I will include here because I think they are relevant to the discussion-- I think his rebuts are quite informative for these particular issues.
I also asked him previously about the "p4" command being difficult to script, and an interesting point you will see in his answers here is that they provide language bindings to their API for many scripting languages (perl, python, ruby...), meaning that using p4 in your scripts is not really what you would do if you were after fine grain control.  Anyway, I played around with P4 and it does return "correct" return codes, but in some cases the whether an error occurs or not is a bit ambiguous depending on you interpretation.  So its not like it always returns zero in all cases which is what I was afraid of.
Working off-line is difficult: if unable to connect to the Perforce server, a user cannot edit files not already opened for edit. The workaround is to manually change permissions on the local file to allow editing, but the user must remember to open the file for edit when reconnected to the Perforce server. Also, the user's local changes will be overwritten if the user does a sync to update their local copy, and those same file(s) were updated on the server in the interim.
It is true that in order to work on files off-line, you must change the permission locally to writable.  However, once you have done work off-line and reconnected to the depot, P4V has a 'Reconcile Offline Work' feature which will visually diff  your workspace against the depot to find files that have changed locally, or been added/deleted locally.  This allows you to build a changelist representing your off-line work to reconcile with the depot.
If any files have changed both in your workspace and the depot, Perforce will allow you to resolve those differences
(merge/accept/reject) as it would in the normal course of on-line work when both you and another user have modified the same file.
These operations are also possible from the command line; the following Knowledge Base article:
  
  Working Disconnected
  http://kb.perforce.com/UserTasks/WorkingDisconnected
describes the process of working disconnected generally, and how to reconcile your changes using 'p4' client commands.
I believe (again, from reviewing other calls) that what informs this perceived shortcoming of Perforce is its difference from other SCM systems, notably subversion, which use a different mechanism for enabling off-line work.  Most notably, Perforce does _not_ cache any metadata locally; only revisions of files that you have synced to your workspace are available when working off-line.  Particularly when compared with other revision systems, Perforce is very restrictive as it does not:
 
* Allow comparison of modifications to the working base.
* Allow files to be scheduled for addition or deletion (a slow reconciliation operation must be performed when reconnected)
* Allow changes to be reverted.
* Allow changed files to be sought and marked.
As with our previous conversation re: error codes, even though Perforce does allow you to work off-line, and provides methods for reconciling off-line work to insure no changes are lost, we do recognize that some users would prefer another approach to off-line work, and I will add you to the existing enhancement request for that.
Automated builds are more difficult with Perforce than with CVS or Subversion, particularly because automated creation of client specifications is awkward.
I'd have to disagree with this statement, for the following reason.
The command that creates client workspaces will allow pre-created client specs to be read from the command line like so:
  
  p4 client -i  < my_client_spec.txt
where the file 'my_client_spec.txt' contains information about the client (most importantly the desired "View:" mapping, Submit options and the like.  It wouldn't be that difficult to write a short script or BAT file to create client specs as needed, assuming you also have a programmatic way to create the spec files.  Even more sophisticated scripting of client creation (and indeed almost any other Perforce
command) is available via the Perforce API, for which a number of language bindings (Perl, Ruby, Python) are available.  
The need to maintain branch specifications complicates merging between branches.
A branch specification is nothing more than a list of source and target mappings that is used in an integration.  The 'integrate'
command can either operate on file paths given in the command line, or via a branch spec.  By storing often-used mappings in a branch spec, you can insure that integrations are performed the same way every time.  Also, more complex mappings can be stored in a branch specification than could be done in a single command line allowing for more complicated relationships between source and targets in a branch.
Of course, branching, integration and merging have the potential to be among the more complex operations in Perforce (indeed in any SCM system, I would maintain).  But branch specs are (or at least are intended to be) a tool to make this process _less_ difficult.
Please don't take my word for it, though; the relevant discussion about codelines and integration are in the User's Guide:
  Chapter 6: Codelines and Branching
  06_codemgmt.html  —Preceding unsigned comment added by 15.235.153.101 (talk) 20:29, 13 November 2007 (UTC)
replies: text: Thank you for your effort to keep the article balanced. This is precisely the kind of argument we shouldn't be having on Wikipedia; Per the verifiability and neutrality policies, Wikipedia articles should rely on reliable sources, for criticsm, rebuttals and everything else — not the opinions of editors. I've taken the liberty of removing both the "Sterngths" and "Weaknesses" sections because they are unsourced. -- intgr [talk] 00:18, 15 November 2007 (UTC)
thread_title:  Responses to the Weakness Section 

message: "All Perforce software you download is fully functional, with the exception of the Perforce Server, which allows only two users and five client workspaces when used without a license. "
You can use Perforce, for free, forever, with no license. This restricts
you to 2 users and 5 client workspaces.
http://www.perforce.com/perforce/price.html#prices
Zero sharp (talk) 06:32, 2 April 2008 (UTC)
replies: text: The section title 'Licensing' has been changed to be more general and the original (_correct_) text restored Zero sharp (talk) 14:57, 2 April 2008 (UTC)
thread_title: Licensing edits

message: I think this article is conspicuously missing a pro/con, strength/weakness section. I see in some of the other talk that there has been discussion about strengths/weakness section and that it had been removed. I think this is a mistake. The comment regarding the removal was regarding verifiability. Personally I think there can be much discussion about the relative strengths and weaknesses without violating the spirit of the wiki policies. For example, I see no problem discussing the offline work problems as being weakness, or the ability to see who else is working on a file as a strength.
Anyone else have an opinion?
::Andy (talk) 02:44, 23 July 2008 (UTC)
thread_title:  Advantages/Disadvantages 

message: I feel not comfortable enough to change this by myself but "Unicode" is a character set (definition of a code space... or sumthin) and not an encoding.
The passage in question is:
"The encoding used for text files in the repository is either ASCII or Unicode, "
Online I found someone mention UTF-8 and UTF-16 together with Perforce...  — Preceding unsigned comment added by 88.152.231.140 (talk) 08:22, 30 November 2011 (UTC)
replies: text: Docs say that a server uses UTF-8 internally in "internationalized" mode. See Internationalization notes. Added this to the article. — Vano 01:08, 9 December 2011 (UTC)
thread_title:  Unicode is no encoding, or is it? 

message: I am a Perforce employee, so I'm avoiding adding this to the article myself because I do not want to create the perception of a conflict of interest.
Perforce recently added support for Git clients, so that a user working entirely in Git can do a "git push" of changes to Perforce.  Unlike the "git-p4" script, the new Git Fusion requires no Perforce software or skills on the developer's system.  This seems to be an important enough change to justify changes to the article, especially the clients section.  Independent source articles are available on TechCrunch and Dr. Dobb's, among other places.
DMarti (talk) 15:59, 8 October 2012 (UTC)
replies: text: Hi DMarti, which release of Perforce added support for git clients? John Vandenberg (chat) 20:33, 4 April 2015 (UTC)
thread_title:  Perforce and git clients 

message: Please add the initial release in the upper-right infobox!!
216.38.147.4 (talk) 18:27, 25 January 2013 (UTC)
thread_title:  Initial Release is Missing 

message: I came here to find out "so, this Perforce thing, what is it and what sort of paradigm does it use?" I have no idea from reading this. But I know it can save stuff as ASCII or UTF-8.
How would we describe Perforce to someone who knows what CVS, Subversion and git are? Is it centralised, distributed, sort-of-both? How does one work with it? What are the answers to newbie questions? etc etc - David Gerard (talk) 10:03, 3 May 2015 (UTC)
thread_title:  Lots of details, no overview