Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Milan's post is well-researched and well-written, but its length demonstrates beyond a shadow of a doubt that the P4SCC model is broken. Storing source control binding info inside the project &amp; solution files is ridiculous. Enforcing (via sccprojectname) that a project be part of only one solution is equally ridiculous.</p> <p>Additionally, P4SCC has a tremendous performance cost in a large solution, as it retrieves info from source control for each file at startup, and maintains that state in memory throughout the development session. It creates extra cruft in the form of information-free .vsscc &amp; vssscc files to support some SCC feature that (AFAICT) Perforce does not use. </p> <p>The ideal Perforce integration looks like:</p> <ul> <li>If I create a new solution, project, or project item, run 'p4 add'.</li> <li>If I change a file, run 'p4 edit'.</li> <li>Some toolbar/context menu integration for revision history, revision graph, timelapse/blame, and 'show in P4 gui'.</li> <li>(nice to have) If I rename a file that exists in the depot, run 'p4 integrate' and 'p4 delete'. If I rename a file opened for add, run 'p4 revert' and 'p4 add'.</li> <li>That's all</li> </ul> <p>We have moved completely away from P4SCC and its bizarre requirements and burdens. Instead we use <a href="http://code.google.com/p/niftyplugins/" rel="noreferrer">NiftyPerforce</a>. There are some bugs, but we find working around these bugs to be much less frustrating than working around the design defects in the Perforce&lt;->VSSCC model.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload