Perforce vs TFS?

Perforce vs TFS?

• Tigers21

  Richard Berg MSFT wrote:

  In general, you'll find that Perforce is very familiar to MS developers and thus had the most influence on the design of TFS.

  Is that because of SourceDepot. So TFS is not built on top off VSS, nice.

  Richard Berg MSFT wrote:

  I think we've improved upon it in several important ways, and we're rapidly catching up in the few areas we had to cut back for v1.

  
  

  Sounds very promising.

  Calvin

  
  
  

• BiBi MeiMei

  TFS does not have Perforce-style server-side checkin triggers. But there are some options here.

  You could do something similar to that using a client-side checkin policy. But where the Perforce trigger would always fire the client-side checkin policy could be over-ridden or simply might not be installed.

  In the end it sounds like you are talking about a feature similar to VSS Sharing. TFS does not support sharing but there is a third-party tool that does. Component Software wrote a tool called TFSLinks (http://www.componentsoftware.com/Products/TFSLinks/) which may address this need.

  Robert.

  
  
  

• Srdjan

  Thank you for the update. Are there plans to improve/change this If so, can you give us a rough timeframe

  To clarify my question a bit, let me give another scenario. Let's suppose that I use a mainline approach, where I have a Main codeline from which all my other codelines branch. So I branch from Main to create 6.0, branch from Main to create 7.0, and then later branch from Main to create 6.1. If I understand what you've said, I could integrate changes from 6.0->Main, 6.1->Main, and 7.0->Main (and vice versa).

  So now I make an enhancement in the 7.0 codeline, and I make a bug fix in 6.0. I can integrate the bug fix from 6.0->Main->6.1 and Main->7.0. Okay so far. But if I integrate the enhancement from 7.0->Main, then the next time I integrate Main->6.1, I pick up an enhancement I don't want. If I don't integrate 7.0->Main, then the next codeline that branches from Main (say for a 7.1 release) won't have all the contents of 7.0. Moreover, I won't be able to migrate bug fixes from 7.0 to 7.1 (via Main), because then Main would have stuff in it that I don't want back in 6.1.

  Have I captured the behavior correctly If so, it seems TFS won't really support a shop that maintains several versions of a product simultaneously. Or is there some other organization you have in mind that TFS would support

  Thanks for your comments.

  
  

• hmayer

  Just small update for for what Robert wrote.

  • We provide web client for TFS (formerly known as TeamPlain).
  • In Orcas our workspace mapping spec gets much better - you can specify one lvel mappings (what Robert described in the example) and you can specify mappings under cloaks.

  
  
  

• robinjam

  Hi

  The answer to your first question is yes.
  TFS has been released on march 20 this year. Please find more informations here:
  http://msdn.microsoft.com/vstudio/teamsystem/team/default.aspx

  Michael

  
  
  

• boonukem

  I am working with perforce for a month after working with TFS for ~ 5 months in my prev place.

  TFS is much better integrated with the VS2005. about 30% of the commands performed from the VS to the perforce goes without effect :(.

  We are checking the migration options from perforce to TFS as we speak

  Avi harush

  
  

• Declan_

  In your example, you can integrate between 6.0 <-> 7.0 and between 6.0 <-> 6.1. What you can't do is integrate directly between 6.1 <-> 7.0. You have to go thru their common parent, or use a baseless merge. In other words, we don't have a direct equivalent for p4 integrate -i. Our /baseless is much dumber.
  
  

• asalcedo

  I would've written almost exactly the same list as Robert. A couple more:
  

  • The Perforce command line is more conducive to shell/script operations. For example, a quick-n-dirty version of our 'tfpt online' could be done just by piping two commands to each other: p4 diff -se //myclient/... | p4 -x - edit. In my opinion our rich, object-oriented client API makes this kind of moot.
    
  • The default Perforce diff/merge tool has a 3-pane view. Ours is 2-pane only. Both allow you to use 3rd-party tools.
  • Perforce has plugins for several non-coding applications like Photoshop. We don't yet -- our partner ecosystem is just getting off the ground.
  • Perforce has counters and triggers. We don't have direct subsitutes. What we do have is much more powerful in my opinion: a complete reporting system built on SQL Reporting Services and OLAP, as well as an extensible SOAP-based eventing system.
  • Perforce has annotate (aka 'blame') built in. Ours is in the tfpt powertoy for now.
    
  • Perforce has obliterate (permanent deletion). Our equivalent is still in development.
  • TFS has checkin policies. Perforce doesn't to my knowledge.
    

  In general, you'll find that Perforce is very familiar to MS developers and thus had the most influence on the design of TFS. I think we've improved upon it in several important ways, and we're rapidly catching up in the few areas we had to cut back for v1.
  
  
  

• Abhishek Chadha

  I have not used or evaluated MKS so I can not give any meaningful feedback there. I have used Perforce for about 6 years though. These are some thoughts off the top of my head - please don't treat this list as comprehensive or necessarily acurate.

  Similarities:

  • Both TFS and Perforce have atomic commits of multiple files grouped into changesets.
  • Both TFS and Perforce are true client/server applications as opposed to a model like VSS where the client is directly editing the "server" contents.
  • There is a high degree of command parity between the too. The basic CRUD operations (add, edit delete) all work substantially the same. Perforce integrate+resolve and TFS branch/merge+resolve have many similar behaviors - if you understand one you should be able to pick up the other.
  • Both systems have an available proxy server (local content cache) to assist with distributed development.
  • Both systems support performing recursive operations.

  Differences:

  • TFS is an integrated suite of products including version control, work item tracking, build, reporting and document management. Additionally TFS has functional integration with the Office suite including Project and, for example, the ability to mass-edit work items through Excel (the point being that the integration is not just "check out" and "check in" behaviors). Perforce is a solid version control system but has very basic defect tracking and reporting.
  • Perforce has per-file revision numbers and changeset numbers. TFS only has changeset numbers.
  • TFS versions directories, Perforce does not.
  • TFS has shelvesets, Perforce does not
  • TFS has rename, Perforce can "fake" rename using integrate+delete.
  • Perforce allows some usages of merging (p4 integrate) that TFS does not allow
  • p4 integrate foo bar
  • p4 integrate baz bar
  • p4 resolve -am bar
  • p4 submit bar
  • Perforce has a more flexible client spec model than TFS's workspace model (specifically it can support including "every item in this folder but not it's child folders" whereas TFS would require you to cloak each child folder manually - consider how both behaviors differ when a new child folder is added).
  • Perforce has native support for Unix, Mac and a web client. TFS customers should consider the TeamPrise (www.teamprise.com) solution which includes access the TFS from Mac, UNIX and within the Eclispe IDE.
  • TFS has better Visual Studio 2005 integration with TFS (and MSSCCI provider for earlier versions) - this is more opinion than hard fact.
  • TFS provides a much more approachable client API than Perforce.

  I'm sure I'm missing some key points and I hope I'm not grossly incorrect on the ones I listed.

  Please correct me or add comments where appropriate.

  Robert.

  
  
  

• Kohl.Mike

  You could also register a handler for the CheckIn event.
  
  

• LeonR

  With perforce, I can use the trigger system (or a command line script) to script an automated integration across branches, so that when a developer checks something into a beta branch, that check-in is automatically propagated to any other branches that care.
  
  Does TFS have any similar mechanism
  
  
  
  
  
  

• vtortola

  I've been told that TFS only allows integrations between branches that have a direct parent-child relationship. Is that true

  For example, let's say I've created a codeline for version 6.0 of my product. I branch a codeline from that for version 7.0. As I understand it, TFS will allow me to integrate from 6.0 to 7.0, and vice versa. But now suppose that I branch from 6.0 to create a codeline for version 6.1. Can I integrate changes from 6.0 -> 6.1 -> 7.0

  Thanks!

  Bill Leonard

  Intergraph Corp.

  
  

• llebron

  This can usually be avoided with good planning. Ordinarily 6.1 should be a branch of 6.0, and 7.1 a branch of 7.0. Alternatively, you could have separate 6.x-main and 7.x-main branches.
  
  Still, there will always be some situations where you want to do an indirect merge. Speaking for ourselves, we usually do this by hand-porting fixes rather than using /baseless. This isn't too much more work than a "real" merge would involve, since the farther two branches have diverged the more manual content merging you'll be doing regardless. The biggest loss is our rich tracking of adds, deletes, renames, etc. I hope we build an indirect merge feature someday but there are a lot of things in front of it.
  
  
• Perforce vs TFS?