问题
A colleague of mine has become excited about the possibilities with PerForce (we basically need an abillity to logistically group patches and changes, and having the SCM support this natively would be very nice). We currently use CVS and are open to all posibillities. We are only few developers who use plain Eclipse and run builds using ant scripts.
Before jumping into the water, I'd like to hear others who on technical reasons can say "Good idea" or "Bad idea". I'd also like to hear how intrusive this is in your daily work.
Edit 2011: Just for the record. We migrated to git - the decisive factor was that we use Eclipse and eclipse.org goes for git, so that we could expect very good IDE integration eventually. We were a bit early out - it was not until Eclipse 3.7 this summer. Today git works very nicely in Eclipse.
EDIT 2015: And it turned out that git ended up as the undisputed winner thanks to github and general IDE support which combined with Maven finally made Java projects IDE-agnostic.
回答1:
Update November 2011:
Using Git, as forcefully advocated by Tilo, is obviously a better choice for a number of reasons (decentralization, private commits, branching, merging, ...).
I am fully aware of the differences between Centralized and Decentralized VCS, as detailed in "Describe your workflow of using version control (VCS or DVCS)".
However, using it in an large enterprise is not easy.
I know. I introduced Git in a large enterprise:
I exposed the general reasons in "Can we finally move to DVCS in Corporate Software? Is SVN still a 'must have' for development?" (while still saying that DVCS is a very valid choice)
But I really detailed the major pain points in installing Git in enterprise in "Distributed Version Control Systems and the Enterprise - a Good mix?".
I have actually presented those pain points in the latest CodeKen 2011 (replacing the ex-DevDays 2011).
The presentation was called "Introducing DVCS in a big corporation", and the tweets were eloquent:
- Grundlefleck: My summary: one does not simply git into enterprise
- ben_sim: @VonC_ redefines pain at #codeken2011: recompiling git and and all its dependencies so you can use it on a production server in enterprise.
The trick with a DVCS is: you still need a "server", a centralized place for all the developers to get a "blessed" version of their repo.
And in a large corporation, those mutualized server are... mutualized, there are a lot of other services already running, which means you cannot just add your Git on it (you won't have the right libraries on that server).
Plus, you will need your own ssh and httpd for your user to push/pull to/from that server.
I have actually automated the installation process for Git and all its dependencies/related services in the GitHub project compileEverything.
So yes, use Git.
On a client PC, you can install and start using it in minutes!
But on a server of a large enterprise? This isn't so easy.
Remember 2009:
- Git support on Windows was possible, but still in progress,
- Git itself didn't include "smart http", which meant the only protocol with authentication for pull/clone and push operations was ssh: convincing users to generate and manage public/private keys is... problematic to say the least.
Https was possible for pull and clone, even if the request was quite inefficient. For push... the setup involved WebDAV and was complex. Smart Http changed all that. - authorization layers was clunky (gitosis), and gitolite was barely starting.
And you need an authorization layer in big enterprise.
Not any user can access to any repository, some of said repositories are quite confidential.
Original answer, back in 2009:
Within a corporation, in a closed centralized environment, Perforce is certainly a good option.
It does checkout your workspace fast, and manage changeset nicely.
It supports "locking by default" which help to see who it working on the same file.
However, you must be in sync with the P4 server at all time, and should have the proper infrastructure to support it, including backup and DRP scenarios: if no server, and you go on working, deleting a file for instance, it will not be restored on successive updates.
The main complaint I hear from the teams using it (since I only do a bit of administration tasks on the tool) is the notion of "Inter-File Branching", a bit confusing at first, but very useful.
Depending on the level of integration of Perforce with your IDE (here eclipse) and editors, the main intrusive aspect will be to make sure to keep your workspace in sync.
Other interesting links for you to read:
- What are the advantages to Perforce?
- What are the benefits of using Perforce instead of Subversion?
回答2:
Perforce is quite heavy weight, esp for a small team.
I'd strongly consider SVN or GIT, for good solid, well supported VCS, then use the available tooling and best practice (all free from your friendly local internet) to support features you need.
For instance with SVN you can setup "bugtraq" properties that help group changes. We just enter the bug ID with every bugfix commit (you even get a nice input field for it on the check-in GUI forms) and then mutli-commit bugfixes are still grouped.
Reasonable blog post on this feature here : http://markphip.blogspot.com/2007/01/integrating-subversion-with-your-issue.html
Again, it's well supported by the tooling making it a decent call for our team of several.
I've heard better things about GIT recently (heck, the Spring guys are using it and that often speaks volumes) but we are on subversion ourselves, so it's all I can comment on.
回答3:
At work we used to use Visual SourceSafe for many years before switching to Perforce last year. It is definitely pricey, and we also have Ant build scripts running under a "build" user which counts as one licensed user which kinda burns. The company paid for a 2-day training seminar so the devs here got up to speed pretty quickly, but there are still questions now and then over how to do foo, etc (I am part of a small group here that supports the other users on Perforce issues - mostly because of the way Visual Studio works, not really Perforce itself).
In terms of using Perforce, I think the biggest difference is in the way Perforce conceptualizes the whole task of keeping track of your changes. For instance, subversion keeps a directory named .svn to hold metadata about the files; with p4, the p4 server itself keeps a list of which files you have. This seems to be the biggest source of issues - someone tells the p4 server to get the latest files for a project, but then manually deletes something. When he/she asks the p4 server for the latest again, the p4 server thinks he/she already has it, so it doesn't get updated. Once people "get" this, it becomes much easier to work with. You just have to tell the server to "remove from workspace" and then get it again.
We have a mix of MS Visual Studio users as well as Eclipse and IntelliJ, and the p4 plugin support for all these work quite well. The daily routine of checking in/out and getting-latest is no different. We are mostly using the basic functionalities and even then it seems to be an improvement over Visual SafeSafe (then again, from the rants I see sometimes on the net over it, probably anything is an improvement over Visual SourceSafe). Just having multiple open changelists at the same time gives some of us a lot of flexibility with how we work. It seems Perforce plugin setups prefer silent checkouts which a lot of users noticed right away, but I like it a lot and I think overall it's an improvement for productivity. The IDEs will highlight file names in a different color, so you can see if somethings been modified - and the p4 changelists always show what you have checked out anyway.
Merging changes when multiple users have checked in changes to a file is pretty easy. The diff tools aren't super-spectacular but we can compare conflicts by line pretty well and just click through the ones we want. I should note that the gui tools are excellent. Most devs here do not use the p4v client, but some do and I for one use it all the time. Did I mention the gui tool is excellent? You can look through all submitted changelists, look at file history, drag and drop one revision onto any other revision and get an instant diff, look at a revision graph which shows you branching history, look at a "time-lapse" view of a file's revisions (very neat feature - drag a slider back and forth across the top and watch the file contents update with each revision).
We have only done a few codeline branches so we're not very experienced with it yet. So far, it has been very easy, and merging changes is also pretty easy. As part of the training course, everyone got a copy of "Practical Perforce", written by Perforce's VP of technology or some such. There's quite a lot of content in there about different methodologies for handling codelines and branching. I think when we used SourceSafe, we were so limited in what it could do that we could only think a certain way - Perforce is so much more flexible that suddenly it's actually possible to have different philosophies on when/how/why codelines should be set up, etc. So in this regard we are still trying out a lot of things with regards to branching and integrating (merging).
P.S. A two-user setup doesn't require a license and only limits you to 5 workspaces. You can evaluate it without a time limit. They also offer free (but unsupported) licensing for open source projects.
回答4:
We're using it, and it definitely has a lot of "goodies" to recommend it. You do have to get used to it a little and think "in Perforce", though.
In general, you have the depot with its own directory structure, and each user has mappings that define where those files/directories will be placed locally. This makes it relatively easy to replace whole parts of the hierarchy with the same parts from a different version, for example, so managing different versions and branches of your product is easier.
It also has support for managing change sets, and checking them in atomically. This can really help when you're trying to figure out what else a certain checkin affected in the rest of the code and not just the file you're currently looking at.
We were using Vault before Perforce, and all-in-all the transition was very smooth without too much lost productivity. :)
回答5:
I use Perforce at work, having previously used CVS at my last job. After the initial learning curve, it is much better to use that CVS. (It's probably easier to learn from scratch than CVS, but I don't have experience that way.) If someone needed a centralized source-control system, I would recommend Perforce, as long as they had the resources to license it.
On the other hand, I've recently been looking at some distributed source-control systems (git, Mercurial, and Bazaar, specifically). They have a lot of features that look very intriguing, especially not requiring the constant server connection. Additionally, you could set up your system to have a "main" server, even with the distributed systems. So I would suggest looking at one of those first, and see if they meet your needs.
回答6:
This question is similar in nature to whether Ant is better than Maven or C# better than Java. People's opinions will be influenced by their battle scars, and most people only have hard, useful experience of 1 to 3 SCM tools so can't give you a balanced opinion.
I would start by sitting down with the team and listing the shortcomings of CVS in terms of features, performance and integrations. Then look at the various SCM tools to see which fit your needs.
Would it hurt to try Subversion, Git, Mercurial, or one of the other open source SCMs for a while? If it turns out they aren't fit for purpose, at least it will give you an idea of what to look for when evaluating Perforce.
回答7:
Most of the benefits of Perforce are also available in Subversion. Subversion is also easier to manage, and doesn't have as rigid a requirement to remain connected to the server.
However, I find the p4 syntax much easier to use and the output is much less cryptic than svn.
回答8:
I've worked with svn, cvs, vss, and now I'm working with perforce. I use to work with baazar for my personal projects, and I have tried git and mercurial.
I don't recommend you perforce at all, and of course i don't recommend you VSS either. It's insecure, unreliable and impractical to work with. It's model it's much more twisted than svn, cvs, git, .. etc .It is also more difficult to use with scripts (as you have to deal with views, clients, and other system variables).
I would recommend you svn with any regular issue tracker. You can customize it throught svn hooks as desired.... In some cases it would be interesting to go distributed (git, mercurial, baazar), but if you don't have an opinion yet, you should start with svn ..
well, thats my opinion of course...
回答9:
Perforce is both expensive and untrustworthy. It doesn't reliably place the correct files in a workspace, leaving with stale versions at times.
There's a lot of things that perforce gets right, and it can handle very very large binary files more simply than other comparable solutions, but that one problem is enough to make me recommend against using it for any project.
回答10:
The year is 2011
The short answer is: No! Use Git!
In the past I have used and administered CVS and Perforce in large companies (~2000 people) for several years. I would strongly suggest to use Git over Perforce any day -- even in a corporate environment. Coming from CVS, it took some time to understand the "Git way" of doing things, but after a short time using it it becomes clear how superior it's paradigm is.
Big companies like Sun Microsystems have demonstrated back in 2006 how switching from centralized version control systems (CVS) to distributed version control systems (Mercurial) is beneficial.
IMHO Perforce is basically a modified CVS, which was obfuscated and complicated to the point that it is extremely painful (and slow) to use, and you will need help from their service department to get things done. It's designed so you will need their service department at one point or the other.. (e.g. when you try to automate processes around it). Oh, and the licenses are really expensive! Why would you want to use such a product? Perforce is really good for job-security of it's administrators though ;-)
Git on the other hand, is a de-centralized Version Control System (VCS), which is much more suitable for how developers work. They can easily create local (throw-away) branches, for feature development or bug-fixing, and keep that code locally under version control, and merge it back to a public repository later if needed. Their temporary branches don't pollute the project. If there is a gate-keeper, they can ask them to pull their changes, or if there is a public repository, they can easily merge their local code changes into it. Merging or creating a Diff , are very frequent operation for developers(!), and are super-fast with Git. On top of that Git is very reliable and will find disk corruptions easily (because it uses SHA1 check-sums).
The LINUX kernel project is using Git very successfully! Check out this talk, and skip to minutes 16..25 where Linux Torvalds mentions Perforce: http://vodpod.com/watch/65074-tech-talk-linus-torvalds-on-git
The long answer is:
Software evolves, so do Version Control Systems (VCS). A lot of things were learned the hard way since the days when Perforce was created. In 1990 the mantra of version control systems was to have a centralized system, which handles all the software projects inside a company. All your source code and branches in one central place... This has proven to be not only difficult and expensive to administer, but has also shown some huge inherent drawbacks:
a simple requirement for a VCS is that if you put a file in the repository, that you get the same file with the same permissions back -- unaltered. With Perforce or CVS this is not the case.
having all kind of disjunct software projects stuffed together in one centralized VCS is really not a good idea
branching in centralized version control systems is usually a huge pain
- creating new branches is slow, requires and admin, and locks up the version control system (in case of Perforce or CVS: several minutes to an hour! sorry you can't check-in, we're creating a new branch...)
- in general branches are globally visible, which means that you need good naming conventions, and that people are usually reluctant to create new branches (to prevent "branchitis") -- still, the result is always a mess of branches.
local development is done outside the version control system, and code gets checked in only after it's "stable" (this by itself invalidates having a VCS in the first place, because the developers could lose several days of work if their local disk crashes)
developers can't just make a local branch for a new feature development, and have it not show up in the centralized VCS
problems typically arise when a company tries to use their "centralized" VCS in several geographical locations (this definitely causes problems and pain with Perforce)
the administrator of a centralized VCS becomes the bottleneck
the centralized model means a performance hit, even to do a simple thing like a diff, because everything implies a network operation
you can not work offline
people need to have commit-access to check-in code
merging with Perforce or CVS is tedious, time-consuming, and therefore expensive! ... and a very frequent job which developers have to do!
回答11:
listen to linus: http://vodpod.com/watch/65074-tech-talk-linus-torvalds-on-git
回答12:
The P4Eclipse Perforce plugin for Eclipse has a Team -> Create Patch option as described here:
http://www.perforce.com/perforce/doc.current/manuals/p4eclipse/topics/patch.html
In case you want to put your toes in the water, Perforce has a free 20-User edition you can test out with free Support:
http://www.perforce.com/downloads/Perforce/20-User
To create patches via the command line in Perforce you can run 'p4 diff2 -u' to generate patch compatible output, but the changes have to be submitted already.
To handle creating patches in Perforce via P4V, you can shelve the pending changelist in one workspace and then unshelve it in the other. Here is a blog post showing shelving in action:
http://www.perforce.com/blog/130304/light-code-review-shelving
Hope you find what you are looking for, whatever you decide.
来源：https://stackoverflow.com/questions/1346031/is-perforce-worth-it