I used Perforce for 5 years in my previous project. Now I've used git for half a year. At this time I think I can say with confidence that if I were to choose a free version control system, I would go with git, but if I had the money, I would choose Perforce.
Not necessarily because Perforce or the Perforce tools are superior, but the way I like to do software development, I would benefit more from Perforce.
So looking at just what really interests me, here are the differences, or rather the parts I really like in Perforce and miss from git to some extent.
- In development I prefer agile ways, in which I regard communication as the most important point - letting others know everything I do. A centralized VCS helps with that. In Perforce I can easily check others' commits, others' work-in-progress stuff, even when they are start working on something which interests me.
- Developers should not think too much about how to use a tool. Git needs constant mental work. Those mental energies should go into the software itself, not the version management.
- Commit messages are often made wrong. In git you are essentially not able to change an already pushed message.
- Developers need easy task organization - Perforce changesets provide a good and easy to use way.
- During pair programming everyone should work at his own desktop. Perforce shelves provide an easy way to share code.
- When someone leaves the office, he might not come the next day, due to some unplanned events, like getting ill, having an accident, or even having traffic problems. Shelving work in progress every day prevents the problems from these.
The arguments against perforce are mostly true, but in my experience, Perforce advantages overwhelm the disadvantages.
And this document from Perforce tends to be true.
Im' a fan of git, but may be more some anti-fan of centralized systems.
ReplyDelete1. Communication. Task trackers invented to this. But if you want to give know, what are you doing -- share your local repos.
2. Howto use. Same is for merging in our lovely VCS. Anyway tools for git now are good. Take for example eclipse egit.
3. You can always rewrite them. Both locally and remotely. But if you do it often -- then your process is bad organized. Take for example ideology of gitflow: do what you want in feauture branch, then squash to more or less adequate commits, then review with your team member. Bad stuff will not pass.
4 & 5. Changesets & shelving -- it's all about just feature branches. Also in decentralized VCS you can connect to your team member and avoid central repo.
You just have much more possibilities. Yes, from 1st time it will be hard, but then!.. Mmm...