There is a config option in VC to allow the editor to edit read only files in memory by default. I like to turn this on one and not have niftyperforce check anything out on keystroke, but rather when you save or build. I also like to bind checkout all modified to CTRL SHIFT E, which I habitually press all the time. Try the above, it should ease up some of the pain :)
Why P4 instead of other version control options? I know it is the traditional old-school, high-end game dev option. Is it still really super-awesome compared to current offerings, or are you using it because you need to/out of habit?
"Why P4 instead of other version control options? I know it is the traditional old-school, high-end game dev option. Is it still really super-awesome compared to current offerings, or are you using it because you need to/out of habit?"
Mostly it's "ain't broke don't fix it". There's a huge amount of value to knowing that something works, what its quirks are, how to deal with the quirks, etc. I absolutely know I can ship a big product with P4 and what the potential problems are and how to deal with them (big problems are possible if you make the mistake of running a 32 bit server for example).
P4 is dramatically better than the old options like SourceSafe or CVS, but supposedly the new cool-kid stuff like Git is better. And then of course the crack smokers do distributed version control.
Basically I want my version control to be incredibly simple and basic and solid and easy to understand and use. I don't want complex concepts or newfangled tech or features or whatever.
Yeah I've been using Mercurial at home which is similar to Git, and of course at work we use Perforce. I really really like Perforce. I prefer P4V to P4Win now (P4V has come a long way). I also really prefer the P4 UI (P4Win/P4V) to the Mercurial/Git offerings. I don't really want to use Windows Explorer integration, but that seems to be the best repo browser there is for Mercurial as far as I could tell, and even that is kinda lame. It's so annoying to get the history up for a single file (maybe I just need to change some context menu items or something and it'll work better).
I also don't like how so many source control systems don't provide single revisions for each file. Git/Mercurial are even worse in that the revision numbers are SHA hashes! Mercurial hides some of this by giving you a single revision number but from what I understand things get hairy when you start branching a lot. I really like being able to tell someone "look at revision 3" and knowing that there have been two checkins before that revision. It's infinitely more useful than saying "oh have a look at revision ".
Also NiftyPerforce and NiftySolution FTW! They are so kick ass. We stripped out all our source control bindings on all our projects at work. Things just work so much better with NiftyPerforce (thanks Jim!). And NiftySolution is really nice. However it had quite a few bugs which I have fixed in our own local copy but have not yet integrated back into the main NiftySolution repo. Not sure how anyone could have used it at the state that it was in.. Unless ours was really out of date :). Stuff like scrolling past the end of the dialog didn't scroll the list, page up/page down/home/end didn't work, and various sorting/selection issues.
I use a local P4 server for all my coding at home. I got so fed up of the incomprehensible popup boxes with went along with trying to get P4SCC and devstudio to play nice with each other that, in the end, I went ahead and bypassed the whole issue. I set the "always writable on workspace" file attribute on all files in my depot and completely removed all the scc binding from devstudio. I have never looked back since. Everything is always write-able so there's no need to check anything out explicitly. When I want to add edited files to my changelist I do a "reconcile offline work..." in P4V or (or a check consistency in P4win). It's also pretty cool when you are working on a different machine and don't have an active connection to the server (which is pretty much always the case when working on my laptop). I'd imagine the consistency checking could get pretty out of hand on larger codebases but for my smallish codebase, it works like a charm.
May 14, 2010 at 8:21 AM
Anonymous said...
I dumped the VS source control mess about 7-8 years ago. Even doing everything by hand for a while (the terrible command line tools of Source Safe/Alien Brain make automating difficult), I felt I was going through FAR less hassle than VS would put me through with its binding roots, startup delays, random fuckups, mysterious reversions, confusing dialogs and some other stuff I've probably forgotten.
I've managed to convert a few people over the years, usually because after a while they note that I never seem to have any bother whatsoever from the source control integration, and wonder what the secret is...
I'm happy every time I hear of anybody uninstalling the VSSC shite :)
"Everything is always write-able so there's no need to check anything out explicitly. When I want to add edited files to my changelist I do a "reconcile offline work..." "
Yeah this is a totally okay way to go if you are a lone developer on your own depot, but it falls apart badly of course if you are actually collaborating.
I have always preferred the explicit-checkout model to the "I just make changes and then merge them later" style of CVS/SVN/etc. I like to be reminded of which files I'm tramping in, especially when I see that someone else has them checked out. Frequently at Oddworld I would check something out and see that some other dev had the same file checked out, and I'd go over and ask them "what are you doing in this file" and it would turn out that we were both fixing the same bug.
It's interesting that you used the source control system to deal with that issue. My experience has always been, you assign the bug in the bug tracker to deal with that problem.
To be clear, I'm not saying that as a criticism... It's like you are living in a parallel dimension where all the same problems are solved with a different combination of version control/bug tracking/IDE features than they are in my dimension, and it's interesting. :)
"It's interesting that you used the source control system to deal with that issue. My experience has always been, you assign the bug in the bug tracker to deal with that problem."
Well no of course we didn't do that, we had a bug database and assigned them to people. But during a normal workday all kinds of little issues come up that you notice yourself in the code that you don't add to the database, you just fix immediately.
For example, somebody checks in some file that works in the game but breaks the editor (and the automatic full build system lets us know). Someone else sees it and goes to fix the editor. Often multiple people would do this at the same time. In an ideal world the guy who broke the game should have tested the editor. Usually we coordinated this pretty well just by having someone yell out "editor build is broken I'm fixing it" but for various reasons that doesn't always work or happen.
I suppose in enterprise environments you have to be more rigorous and before you do *anything* to the code you add it to the bug database and you get permission before you can check out files and blah blah.
I always try to follow the practice of having mini "releases" from the code department to the rest of the team. (I can't believe how many game developers don't do this and just let artists work on the live branch all the time, that's insanely foolish). Usually these mini releases would be once a day, but sometimes more often or less often. The rest of the team would get a version that we considered to be reasonably stable and usable, and they would report bugs on that version. In the mean time we in code would be working on a new version that had some changes that other people didn't see yet. Usually we would coordinate work on these new changes just by yelling across the hall at each other.
Also BTW once you learn the quirks of P4SCC it's really not that bad. The secrets to working with it well are :
1. When possible add the project to source control before you do anything else. Then it will just be happy and you can go.
2. When it has trouble and starts popping up awful prompt boxes about projects failing to bind or shit not being under binding root or whatever - DO NOT try to get through it in MSDev. Immediately ctrl-alt-delete and kill the MSDev process!
3. After you kill the MSDev process, open the SLN and VCPROJ in your text editor and fix the binding by hand.
May 14, 2010 at 11:37 AM
Anonymous said...
"When it has trouble and starts popping up awful prompt boxes about projects failing to bind or shit"
Usually, I simply open the given box, unbind everything, rebind everything and voilà!
PS: yes, there's one of these #$%^&*@#$%^&! accent on the a of voilà ;)
""I suppose in enterprise environments you have to be more rigorous and before you do *anything* to the code you add it to the bug database and you get permission before you can check out files and blah blah.""
The other way is to create a Perforce addon that would compile files affected by your change in most/all build mode. This slows down check-ins, but it gets rid of most broken builds.
I'm trying using P4 in MSDev with NiftyPerforce and no P4SCC.
What this means is VC thinks you have no SCC connection at all, your files are just on your disk. You need to change the default NiftyPerforce
settings so that it checks out files for you when you edit/save etc.
Advantages of NiftyPerforce without P4SCC :
1. Much faster startup / project load, because it doesn't go and check the status of everything in the project with P4.
2. No clusterfuck when you start unconnected. This is one the worst problems with P4SCC, for example if you want to work on some work projects
but can't VPN for some reason, P4SCC will have a total shit fit about working disconnected. With the NiftyPerforce setup you just attrib your
files and go on with your business.
3. No difficulties with changing binding/etc. This is another major disaster with P4SCC. It's rare, but if you change the P4 location of a
project or change your mappings or if you already have some files added to P4 but not the project, all these things give MSdev a complete
shit-fit. That all goes away.
Disadvantages of NiftyPerforce without P4SCC :
1. The first few keystrokes are lost. When you try to edit a checked-in file, you can just start typing and Nifty will go check it out,
but until the checkout is done your keystrokes go to never-never land. Mild suckitude. Alternatively you could let MSDev pop up the dialog
for "do you want to edit this read only file" which would make you more aware of what's going on but doesn't actually fix the issue.
2. No check marks and locks in project browser to let you know what's checked in / checked out. This is not a huge big deal, but it is a nice
sanity check to make sure things are working the way they should be. Instead you have to keep an eye on your P4Win window which is a mild
productivity hit.
One note about making the changeover : for existing projects that have P4SCC bindings, if you load them up in VC and tell VC to remove the
binding, it also will be "helpful" and go attrib all your files to make them writeable (it also will be unhelpful and not check out your
projects to make the change to not have them bound). Then NiftyPerforce won't work because your files are
already writeable.
The easiest way to do this right is to just open your vcproj's and sln's in a text editor and rip out all the binding bits manually.
I'm not sure yet whether the pros/cons are worth it. P4SCC actually is pretty nice once it's set up, though the ass-pain it gives when trying
to make it do something it doesn't want to do (like source control something that's out of the binding root) is pretty severe.
ADDENDUM :
I found the real pro & con of each way.
Pro P4SCC : You can just start editting files in VC and not worry about it. It auto-checks out files from P4
and you don't lose key presses. The most important case here is that it correctly handles files that you have
not got the latest revision of - it will pop up "edit current or sync first" in that case. The best way to use Nifty
seems to be Jim's suggestion - put checkout on Save, do not checkout on Edit, and make files read-only editable in memory.
That works great if you are a single dev but is not super awesome in an actual shared environment with heavy contention.
Pro NiftyP4 : When you're working from home over an unreliable VPN, P4SCC is just unworkable. If you lose
connection it basically hangs MSDev. This is so bad that it pretty much completely dooms P4SCC.
ARG actually I take that back a bit, NiftyP4 also hangs MSDev when you lose connection, though it's not nearly as bad.
"05-13-10 - P4 with NiftyPerforce and no P4SCC"
18 Comments -
There is a config option in VC to allow the editor to edit read only files in memory by default. I like to turn this on one and not have niftyperforce check anything out on keystroke, but rather when you save or build. I also like to bind checkout all modified to CTRL SHIFT E, which I habitually press all the time. Try the above, it should ease up some of the pain :)
Cheers,
Jim
May 13, 2010 at 8:18 PM
Why P4 instead of other version control options? I know it is the traditional old-school, high-end game dev option. Is it still really super-awesome compared to current offerings, or are you using it because you need to/out of habit?
May 13, 2010 at 9:34 PM
"Why P4 instead of other version control options? I know it is the traditional old-school, high-end game dev option. Is it still really super-awesome compared to current offerings, or are you using it because you need to/out of habit?"
Mostly it's "ain't broke don't fix it". There's a huge amount of value to knowing that something works, what its quirks are, how to deal with the quirks, etc. I absolutely know I can ship a big product with P4 and what the potential problems are and how to deal with them (big problems are possible if you make the mistake of running a 32 bit server for example).
P4 is dramatically better than the old options like SourceSafe or CVS, but supposedly the new cool-kid stuff like Git is better. And then of course the crack smokers do distributed version control.
Basically I want my version control to be incredibly simple and basic and solid and easy to understand and use. I don't want complex concepts or newfangled tech or features or whatever.
May 13, 2010 at 9:59 PM
Yeah I've been using Mercurial at home which is similar to Git, and of course at work we use Perforce. I really really like Perforce. I prefer P4V to P4Win now (P4V has come a long way). I also really prefer the P4 UI (P4Win/P4V) to the Mercurial/Git offerings. I don't really want to use Windows Explorer integration, but that seems to be the best repo browser there is for Mercurial as far as I could tell, and even that is kinda lame. It's so annoying to get the history up for a single file (maybe I just need to change some context menu items or something and it'll work better).
I also don't like how so many source control systems don't provide single revisions for each file. Git/Mercurial are even worse in that the revision numbers are SHA hashes! Mercurial hides some of this by giving you a single revision number but from what I understand things get hairy when you start branching a lot. I really like being able to tell someone "look at revision 3" and knowing that there have been two checkins before that revision. It's infinitely more useful than saying "oh have a look at revision ".
Also NiftyPerforce and NiftySolution FTW! They are so kick ass. We stripped out all our source control bindings on all our projects at work. Things just work so much better with NiftyPerforce (thanks Jim!). And NiftySolution is really nice. However it had quite a few bugs which I have fixed in our own local copy but have not yet integrated back into the main NiftySolution repo. Not sure how anyone could have used it at the state that it was in.. Unless ours was really out of date :). Stuff like scrolling past the end of the dialog didn't scroll the list, page up/page down/home/end didn't work, and various sorting/selection issues.
Sam
May 13, 2010 at 10:25 PM
I loathed using P4. I dunno how you can stand it when there is a better solution in git.
May 14, 2010 at 4:27 AM
I use a local P4 server for all my coding at home. I got so fed up of the incomprehensible popup boxes with went along with trying to get P4SCC and devstudio to play nice with each other that, in the end, I went ahead and bypassed the whole issue. I set the "always writable on workspace" file attribute on all files in my depot and completely removed all the scc binding from devstudio. I have never looked back since. Everything is always write-able so there's no need to check anything out explicitly. When I want to add edited files to my changelist I do a "reconcile offline work..." in P4V or (or a check consistency in P4win). It's also pretty cool when you are working on a different machine and don't have an active connection to the server (which is pretty much always the case when working on my laptop). I'd imagine the consistency checking could get pretty out of hand on larger codebases but for my smallish codebase, it works like a charm.
May 14, 2010 at 8:21 AM
I dumped the VS source control mess about 7-8 years ago. Even doing everything by hand for a while (the terrible command line tools of Source Safe/Alien Brain make automating difficult), I felt I was going through FAR less hassle than VS would put me through with its binding roots, startup delays, random fuckups, mysterious reversions, confusing dialogs and some other stuff I've probably forgotten.
I've managed to convert a few people over the years, usually because after a while they note that I never seem to have any bother whatsoever from the source control integration, and wonder what the secret is...
I'm happy every time I hear of anybody uninstalling the VSSC shite :)
May 14, 2010 at 9:52 AM
"Everything is always write-able so there's no need to check anything out explicitly. When I want to add edited files to my changelist I do a "reconcile offline work..." "
Yeah this is a totally okay way to go if you are a lone developer on your own depot, but it falls apart badly of course if you are actually collaborating.
I have always preferred the explicit-checkout model to the "I just make changes and then merge them later" style of CVS/SVN/etc. I like to be reminded of which files I'm tramping in, especially when I see that someone else has them checked out. Frequently at Oddworld I would check something out and see that some other dev had the same file checked out, and I'd go over and ask them "what are you doing in this file" and it would turn out that we were both fixing the same bug.
May 14, 2010 at 10:24 AM
It's interesting that you used the source control system to deal with that issue. My experience has always been, you assign the bug in the bug tracker to deal with that problem.
To be clear, I'm not saying that as a criticism... It's like you are living in a parallel dimension where all the same problems are solved with a different combination of version control/bug tracking/IDE features than they are in my dimension, and it's interesting. :)
May 14, 2010 at 10:52 AM
"It's interesting that you used the source control system to deal with that issue. My experience has always been, you assign the bug in the bug tracker to deal with that problem."
Well no of course we didn't do that, we had a bug database and assigned them to people. But during a normal workday all kinds of little issues come up that you notice yourself in the code that you don't add to the database, you just fix immediately.
For example, somebody checks in some file that works in the game but breaks the editor (and the automatic full build system lets us know). Someone else sees it and goes to fix the editor. Often multiple people would do this at the same time. In an ideal world the guy who broke the game should have tested the editor. Usually we coordinated this pretty well just by having someone yell out "editor build is broken I'm fixing it" but for various reasons that doesn't always work or happen.
I suppose in enterprise environments you have to be more rigorous and before you do *anything* to the code you add it to the bug database and you get permission before you can check out files and blah blah.
I always try to follow the practice of having mini "releases" from the code department to the rest of the team. (I can't believe how many game developers don't do this and just let artists work on the live branch all the time, that's insanely foolish). Usually these mini releases would be once a day, but sometimes more often or less often. The rest of the team would get a version that we considered to be reasonably stable and usable, and they would report bugs on that version. In the mean time we in code would be working on a new version that had some changes that other people didn't see yet. Usually we would coordinate work on these new changes just by yelling across the hall at each other.
May 14, 2010 at 11:18 AM
Also BTW once you learn the quirks of P4SCC it's really not that bad. The secrets to working with it well are :
1. When possible add the project to source control before you do anything else. Then it will just be happy and you can go.
2. When it has trouble and starts popping up awful prompt boxes about projects failing to bind or shit not being under binding root or whatever - DO NOT try to get through it in MSDev. Immediately ctrl-alt-delete and kill the MSDev process!
3. After you kill the MSDev process, open the SLN and VCPROJ in your text editor and fix the binding by hand.
May 14, 2010 at 11:37 AM
"When it has trouble and starts popping up awful prompt boxes about projects failing to bind or shit"
Usually, I simply open the given box, unbind everything, rebind everything and voilà!
PS: yes, there's one of these #$%^&*@#$%^&! accent on the a of voilà ;)
May 14, 2010 at 11:41 AM
p4scc is retarded. The way:
- turn off the "allow editing of read-only files;"
- don't get Nifty to autocheckout
- map F1 to Connect.NiftyEdit (since F1 is obviously not useful other than to hang the IDE for indeterminate amounts of time)
May 14, 2010 at 4:55 PM
""I suppose in enterprise environments you have to be more rigorous and before you do *anything* to the code you add it to the bug database and you get permission before you can check out files and blah blah.""
The other way is to create a Perforce addon that would compile files affected by your change in most/all build mode. This slows down check-ins, but it gets rid of most broken builds.
May 14, 2010 at 6:09 PM
Hmm, there's no NiftyPerforce for VS 2008, right? I would be psyched to try it if there is one.
May 19, 2010 at 7:10 AM
There is:
http://code.google.com/p/niftyplugins/downloads/list
May 19, 2010 at 9:57 AM
Sam, I'd love to get patches for any issues you've found (I do use the issue system on google code, but heck just send me an email otherwise).
Maffy, the plugin supports both VS2005 and VS2008 in the latest releases (it's the same installer).
June 3, 2010 at 8:22 PM
(dummy comment to get emails for replies).
June 3, 2010 at 8:23 PM