My hovercraft is full of eels

I'm pretty sure I saw something about offline coming in the next version. ssh makes sense for them, its better than inventing there own protocol and has the client authentication integrated nicely with your existing SSO.

BTW for the command line tool you can make a file i.e. p4.config and put the properties in there. p4 will search up the directories until it finds the file and uses that. useful if you have multiple clientspecs.

But the tools in general are missing a lot. I much prefer the subversion tool support. But I gather a lot of the benefits of perforce are for the "fulltime" source control guys. i.e. projects that have dedicated perforce admins for project or branching setup and merges etc.

Creating a short lived development branch seems so much more complicated than it should be. In contrast, subversion makes it trivial.

I don't mind the SSH thing I just want the tooling to do it for me. SVN manages no problem and perforce has been around a lot longer.

Offline support would be good.

Nice tip on the p4.config.

The other big thing that really irks me about the tooling is the whole changeset rubbish. Why do I need to inform perforce that I'm about to edit a file? Surely the fact that it's modified is enough to know?

The idea that the full-time source control guys are the centre of the SCM universe is ludicrous. We end up in a situation where developers have to jump through hoops so the support staff have it easy. How hard can it be to ship with tooling that just works without needing to write custom scripts?

How's this for a workflow: http://www.perforce.com/perforce/technotes/note002.html

Enough said!

Thanks for the tips. I'll give them a try.

The name of the file actually needs to match the P4CONFIG environment variable. so something like p4.config. File content is just newline seperated KEY=value.

In general the Eclipse plugin takes care of a lot of these things. Just start typing and it will open the file for edit. Instead of running scripts, eclipse has features like "check consistency". This is a lot easier than the workflow you linked to, but essentially does the same thing.

A couple of your issues seem related to the different models subversion and perforce use. Subversion has .svn directories at every level in the client. In fact the subversion server has no need to know about any of the clients. Perforce instead has no such directories and relies on the server-side clientspec. Perforce knows about every client, including what directory on disk you are using. Maybe they can do really advanced things with merging etc. But I guess it really shows the different focus i.e. Open Source projects with loosely bound teams vs. enterprise developers with SCM guys :)

If you saw the mess of branches etc the SCM guys have to deal with in some places *cough*, you would probably be more understanding about them choosing a tool themselves :)

I've quite positive about perforce, but I certainly prefer subversion for my own projects. Luckily these two seem to be the chosen SCM tools for integration with things like maven. The maven - eclipse - perforce or svn - JIRA combination is pretty nice.

BTW 2006.2 apparently will have offline support.

Perforce requires a bit of a shift from CVS/Subversion, but I think you are being a little hard on it :):

1) Once you have the P4CONFIG stuff set up, things work very nicely
2) I find it strange that people suggest Perforce requires full time SCM guys. It has got to be just about the simplest piece of sofware to set up and administer that you can get. In fact, simpler to set up than either CVS or Subversion in my experience, and with little or no ongoing admin.
3) Perforce fixes things that plain suck in CVS and Subversion. The main thing that comes to mind is support for merge tracking: i.e. remembering what merges have happened between branches, so that a repeated merge Just Works. I can't believe Subversion does not have this feature yet: manually tracking merged revisions is a major PITA. Perforce also understands merges between indirectly-related branches: in general the merging support is much more powerful.
4) It is quite possible to specify which files to perform a diff on. For example, you can give file names as arguments, or '...' to mean everything under the current directory.
5) I also fail to understand the commentor that believes branching is simpler in Subversion than Perforce. Creating a branch is cheap and trivial in Perforce and very similar to the way it works in Subversion. Couple this with the real merging support I mentioned above and branching is much less painful in Perforce.

You have hit the nail on the head with the biggest pain in Perforce, though: working offline. It is just not designed to work offline at all at the moment. Requiring an explicit checkout is not big deal (any decent IDE/editor should support, possibly via integration, doing it automagically for you). Needing a constant connection to the server, however, is a problem for the way many people work. That cost outweighs the small benefits (e.g. no hidden directories in your workspace, the ability to see files that other people are editing). I'm surprised they didn't attack this sooner: I'm guessing the rise of Subversion may have prompted it.

Agreeing with Jason. Perforce branching/merging is divine. After using perforce or subversion there's no way I could ever go back to CVS. I don't have much experieince merging in subversion so I can't really compare, but Perforce is wonderful. This is where it's nice having logical changesets; keep your bugfixes in atomic changesets as much as possible, branch properly, and you can pretty easily move that fix from branch to branch as long as the files share a common ancestor. It's pretty impressive imho.

I think the main reason perforce needs to know that you're editing a file is for speed. It's a tradeoff. By you telling it what files you will be editing, you get lighting fast diffs/updates. Because it doesn't have to scan the whole tree, checking the revisions on every file. Finding out what files you need probably boils down to a database query or two internally. If you don't feel like doing that, you can always just enable the workspace option that checks all files out as read/write, and then just do a "check consistency" to scan all of your files for missing files and changed versions.

The biggest annoyance for me is that it's common for people coming from some other systems (notably VSS) to think that because someone has the file open for edit, it's locked and can't be checked out for edit. So I get emails saying "can you un-edit or check in file X so I can work on it?" That I hate, especially when the merging/conflict resolution is pretty good. But it's very nice to be able to have that extra information, that someone is currently editing a file. That way I can see if someone is editing the file, and do a quick head check to see if I should continue my edit or wait for it to be available. "So and So has that file checked out, and they're great at merging and I just have a small fix to put in, so I'll go ahead and do it." etc. Comes in handy on a large, distributed team.

It does totally suck for offline usage, which is a bummer for me since I have a looong commute via train. However, given the wide variety of choices that our "enterprise" could have chosen as the standard, Perforce is head and shoulders above the likely other candidates. There are things I prefer about perforce, and things I prefer about subversion, but both are in a totally different league than CVS.

The workflow I use for offline usage is to just edit the files locally without opening them for edit before I leave. When I get back, I run the consistency check which identifies all of the changed/removed files. It doesn't catch added files, so I just keep track of them in a little notepad window and remember to add them manually; I haven't really been bitten by adding a ton of files yet so I haven't scripted it yet.

So, all those in favour of Perforce seem to suggest that the reason is branching and merging. Not something I do on a daily basis I must say. What I do on a daily basis is add files, delete files, edit files. Gee, seems like something I'd have in common with just about every developer on the planet but for some reason those things are made difficult. I really don't think 'p4 -se diff | xargs p4 edit && p4 -sd diff | xargs p4 delete' should even be considered "tooling" and that's connected to a server! Otherwise I need to manually p4 edit each file as I go. What a joke. And manually tracking added files? Give me a break!

Perforce may well be a sensational tool for all those really nasty jobs but it seems a lot like taking a 12-gear semi-trailer to the supermarket to do my weekly grocery shopping.

I want it to be simple to do the simple things and so far no one seems to be able to show me a simple way to do anything--besides tasks I don't care about or involving a lot fo custom scripting.

Don't get a man to do a boy's job? ;-)

Anyway, someone suggested I buy the O'Reilly book so I may wel go and have a look at it today.

As folks have said, Perforce is FAR superior when it comes to branching and merging. It's not even a contenst in my opinion. I use both Perforce and Subversion on a regular basis. My day job (Adobe) uses Perforce, and simply couldn't be done with Subversion, and all my own projects use Subversion, mainly because it's sufficient for personal stuff where I'm not doing much branching, is easy to get hosting/server support for, and works more easily with Rails (I've been working on integrating P4 support as equivalent to the --svn switch, but haven't done it in a way I like/would publish yet). I agree that P4 is weak for remote/unconnected work.

My take is this. If you doing smaller projects or especially one person projects, then Subversion is totally fine. Also, if you simply can't spend money on SCM, then SVN is good. And, further, if you don't use branches much or at all, then SVN would be my choice. I do prefer not having to explicitly check out a file. Also, if you work a ton unconnected, then SVN may win for that. But, if you work with large teams, on massive code bases, and especially cross platform where you say are compiling code on two different systems, then P4 will be the way to go. The branching, as said, is just a world of difference, and significantly improves large project work.

For example, one of the things we do is use a "sandbox" model. I think this is maybe even required with tools like Clear Case. But, the basic deal is that every developer has their own branch, that is their sandbox. They do their daily work here. It also allows you to do something like write the code and test on Mac, then check in just to your sandbox, sync up on your Windows and/or Linux box, do builds and test there, and then when it's dialed in on all platforms, you then integrate/merge your changes into the main branch. This sandbox model is also great for doing more fine grained version control, individual backups, and so on, while working on a feature, and then merge that to main only when it's ready for wider consumption. Working this way in Subversion is, well, I'll say I just wouldn't do it, or it'd be painful. In Perforce, it's flat out trivial. P4 can do all the merging (just about) for you, there is nothing you have to keep track of yourself, in terms of when things were merged, what state the various branches are in, etc. As someone else said, it just works. This sucks in every other SCM tool I've ever used (SVN, CVS, VSS, and a couple other less known and oddball variants). Also, once you start working in this style, you likely won't want to go back. It's a bit of overhead if you are a one person shop, although even there it may work well for you depending on how you do releases and version management, etc. In my day work, I won't work any other way now. But, for my side/personal projects, I just use SVN, because it's a better fit.

In the end, there is no one SCM that works best for all people. Choose what works best for you and/or your team.

P4V for some time now has a Reconcile command, which makes it easy to work offline.
Perforce is free to use for max. 2 users and 5 workspaces.