I like Perforce, too, but it does have some bad points. First the good stuff: the commands are extremely intuitive, the branching and merging model kicks CVS butt, it has atomic commits, and at least for small organizations, it's quite fast.
The bad points are:
- There is no equivalent of a ".cvsignore" file, so it is hard to figure out what you need to "p4 add". I really like the ability to run "cvs update" and see what I've changed and what files I need to add. You can of course write a shell script to do figure this out. However, it is handy to have it built into the application, and since it seems like a pretty simple feature to implement, I really don't know why the Perforce developers haven't bothered.
- Perforce is designed to help you avoid having two developers working on the same file at the same time. The idea is that you "p4 edit" each file before starting to make changes and get an (advisory) message if someone else has already done this. This is not a bad idea, but sometimes you have a project and very often you have a branch where there is only one developer, or where this is otherwise unnecessary. Having to "p4 edit" all the right things before submitting is kind of annoying at times, even though there is a command to find all such files for you. In general, I prefer the CVS model, where you just edit things and check them in, though I realize there are times when the explicity edit model is preferable.
- Quite a bit of the processing happens on the server side, I think, so you can need a big server if you have a lot of developers. I worked in one environment, with several hundred developers, where performance was an issue.
And of course,
- It's not F/OSS, some of the data files are stored in a proprietary binary format, and you have to pay for it. On the other hand, compared to Clearcase or Bitkeeper... it's cheap.
Nonwithstanding the bad points, the branching and merging support was enough to make me talk my boss into springing for it. At that time, Subversion was not far enough along that I felt comfortable relying on it for production (and I don't think it had a Windows client either, not sure if it does now, which was a requirement for one of our developers).
I think the change from the LGPL to the GPL was designed precisely for the purpose of forcing more people to purchase commericial licenses. Unless I'm misunderstanding the situation, under the LPGL, you can link your (propriety) code against their libraries without having to distribute your source code. Under the GPL, this is not the case - linking is not "mere aggregation" and you now have to distribute the source, cough up $$$, or stop upgrading MySQL. If they were distributing the code ONLY under xGPL, the change would clearly be an endorsement of F/OSS, but because of the dual license, it seems more like an attempt to restrict what users can do with their software.
Slashdot Mirror
I like Perforce, too, but it does have some bad points. First the good stuff: the commands are extremely intuitive, the branching and merging model kicks CVS butt, it has atomic commits, and at least for small organizations, it's quite fast. The bad points are: - There is no equivalent of a ".cvsignore" file, so it is hard to figure out what you need to "p4 add". I really like the ability to run "cvs update" and see what I've changed and what files I need to add. You can of course write a shell script to do figure this out. However, it is handy to have it built into the application, and since it seems like a pretty simple feature to implement, I really don't know why the Perforce developers haven't bothered. - Perforce is designed to help you avoid having two developers working on the same file at the same time. The idea is that you "p4 edit" each file before starting to make changes and get an (advisory) message if someone else has already done this. This is not a bad idea, but sometimes you have a project and very often you have a branch where there is only one developer, or where this is otherwise unnecessary. Having to "p4 edit" all the right things before submitting is kind of annoying at times, even though there is a command to find all such files for you. In general, I prefer the CVS model, where you just edit things and check them in, though I realize there are times when the explicity edit model is preferable. - Quite a bit of the processing happens on the server side, I think, so you can need a big server if you have a lot of developers. I worked in one environment, with several hundred developers, where performance was an issue. And of course, - It's not F/OSS, some of the data files are stored in a proprietary binary format, and you have to pay for it. On the other hand, compared to Clearcase or Bitkeeper... it's cheap. Nonwithstanding the bad points, the branching and merging support was enough to make me talk my boss into springing for it. At that time, Subversion was not far enough along that I felt comfortable relying on it for production (and I don't think it had a Windows client either, not sure if it does now, which was a requirement for one of our developers).
I think the change from the LGPL to the GPL was designed precisely for the purpose of forcing more people to purchase commericial licenses. Unless I'm misunderstanding the situation, under the LPGL, you can link your (propriety) code against their libraries without having to distribute your source code. Under the GPL, this is not the case - linking is not "mere aggregation" and you now have to distribute the source, cough up $$$, or stop upgrading MySQL. If they were distributing the code ONLY under xGPL, the change would clearly be an endorsement of F/OSS, but because of the dual license, it seems more like an attempt to restrict what users can do with their software.