Hi dudes. I'm considering that maybe I'll use PERFORCE and I'd like to know what do you think about this program (apart from price). Now I use SVN but sometimes I have perfomance problems. My pc almost freezes (can't use any other program) a few seconds when I update, sometimes even minutes (My repository has a lot of art resources). BTW: I don't care about free software or paid-software, I just want better software. Thanks for suggestions.

I use Perforce at work and at home - It's free for up to 2 users (Or it might be 3, I can't recall offhand).

I've used Tortoise SVN briefly, and I personally think that Perforce is much better on Windows systems.

Just my 2p.

Hi,

">This is Linus T. about git. Besides several other SCM-Systems, he also mentions perforce.

Maybe this is not exactly what you where looking for, but he makes some imho very intersting points about distributed or monolythic SCMs.

It's not so long ago, that I was also searching for an alternative to SVN, and finally changed to using Mercurial via TortoiseHg.

Up to now, I'm really happy I did.

Best Jochen

Well, perforce really is SVN on steroids, ie. it's faster, and has decent merging, but the paradigm is mostly the same (which is probably what you're looking for). It is really good at really fucking things up if something goes wrong though (for example when it tries to delete a file that you have checked out), which very often leaves your repository in an inconsistent state, which is pretty much only fixable by deleting the whole thing, and recreating your whole tree again.

But given that you have lots of art resources in your tree, the fact that perforce is so fast with big trees may make it the best option nonetheless, dispite it's quirks.

[Edited by - quasar3d on April 2, 2009 8:53:20 AM]

Quote: Original post by jochen
Hi,

">This is Linus T. about git. Besides several other SCM-Systems, he also mentions perforce.

Maybe this is not exactly what you where looking for, but he makes some imho very intersting points about distributed or monolythic SCMs.

It's not so long ago, that I was also searching for an alternative to SVN, and finally changed to using Mercurial via TortoiseHg.

Up to now, I'm really happy I did.

Best Jochen

Yep, distributed systems are really great, but they are pretty much useless on reprositories that also contain the art, as it always copies the full history locally, and art resources generally can't be diffed very well, so your full history will be *huge*

Quote: Original post by quasar3d
Yep, distributed systems are really great, but they are pretty much useless on reprositories that also contain the art, as it always copies the full history locally, and art resources generally can't be diffed very well, so your full history will be *huge*

I'm not really here to advocate for or against perforce, but I'd like to point out that the current generation of DVCS (git, mercurial, etc.) can handle binary deltas just fine, unless the format you're using retains little common data after incremental updates due to whole-file compression or some such feature.

[Edited by - crusadingknight on April 2, 2009 8:25:23 AM]

Quote: Original post by quasar3d
It is really good at really fucking things up if something goes wrong though (for example when it tries to delete a file that you have checked out), which very often leaves your repository in an inconsistent state, which is pretty much only fixable by deleting the whole thing, and recreating your whole tree again.

All you need to do then is revert the file and sync again (If you want to lose changes), or copy the file elsewhere, sync again, and then re-add the file (If you want to keep changes).

I've never encountered any problems that have meant you need to re-create anything, and the only time I've lost work is when I've reverted something I didn't mean to - and that's my own fault; Perforce says "Reverting file(s) will overwrite any edits to the file(s) Proceed with Revert?".

Quote: Original post by quasar3d
...and art resources generally can't be diffed very well, so your full history will be *huge*

And that's why you use meaningful and accurate checkin comments [smile]

Quote: Original post by Evil Steve

Quote: Original post by quasar3d
It is really good at really fucking things up if something goes wrong though (for example when it tries to delete a file that you have checked out), which very often leaves your repository in an inconsistent state, which is pretty much only fixable by deleting the whole thing, and recreating your whole tree again.

All you need to do then is revert the file and sync again (If you want to lose changes), or copy the file elsewhere, sync again, and then re-add the file (If you want to keep changes).

I've never encountered any problems that have meant you need to re-create anything, and the only time I've lost work is when I've reverted something I didn't mean to - and that's my own fault; Perforce says "Reverting file(s) will overwrite any edits to the file(s) Proceed with Revert?".

You're probably right, I'm sure it's not really a bug in the system, but that I'm just making a mistake somewhere, it's just that in my experience perforce trees happen to have problems more often than with any of the other systems I've used (in your working tree that is, the repositories are pretty solid), It's very likely that it's just because I don't really know the system very well, but I do think that in comparison to other systems, perforce is less forgiving to "tinkering" than most other systems.

Quote:

Quote: Original post by quasar3d
...and art resources generally can't be diffed very well, so your full history will be *huge*

And that's why you use meaningful and accurate checkin comments [smile]

I don't see the connection between them? :)

Quote: Original post by quasar3d

Quote:

Quote: Original post by quasar3d
...and art resources generally can't be diffed very well, so your full history will be *huge*

And that's why you use meaningful and accurate checkin comments [smile]

I don't see the connection between them? :)

Yeah, I was thinking somewhat tangentially then - I meant that you shouldn't really need to diff art files; you should be able to use the checkin comment to tell what changed.

Ah, then we were indeed talking past each other. What I meant was that a new revision of an art file can't be stored as a relatively small delta from the previous one, so each modification to that art file would increase the disk size of your repository quite a lot (as the old one can't be thrown away, as it's still part of the history), and thus your git tree, which always copies the whole history locally, would be huge. With code files, this whole history is generally much smaller, as the deltas between two subsequent revisions generally take much less space than the files they apply to.