>>>Ok, forget the software being used (Vault) for now. Craig says they don't use branching, and Tracy says they use it just fine. Let's say we do use branching so we can keep our current production code (bug fixed, etc.) separate from projects. What is the best way to implement that? The developers all work remotely and access a server at the company location. Any thoughts welcome because I am getting really (really) tired of having to constantly reconcile our code manually and risk bad code getting out the door.
>>
>>Practice makes perfect. Get used to it.
>>
>>Look, the question is philosophical. You have created two versions of something. What do you want to rely on - software which will try to be smart and merge [the text versions of] them for you, or do you want to be in control and know exactly what's going on? I, for one, have found that software can't be that smart - even Beyond Compare (or Vault's diff client) will find differences in wrong places, and suggest ridiculous things.
>>
>>There's no other AI available nowadays, but diff the text (.prg or scctextX.prg generated text file) and judge for yourself which changes need to be migrated into the new version and which not.
>
>Yeah, got that part. Thanks. What I'm looking for is how best to handle production vs projects. Keeping the version separate, yet in sync. If you have anything along those lines I would love to hear it. Processes? Ways of communication between developers? Tools? Things that work vs things that don't? I'm not the first one to try and keep things straight so I'm asking how best to do that.
Comments everywhere, specially in source control when you checked something in. Check in frequently, and in small chunks. If you're checking in a dozen files, but for four reasons, check them in in four batches, reason by reason. So just looking at the history will give you some idea on what's up with this file.
Comment in code - by Rox's Laws:
1) don't tell me what you're doing, I can read the code. Just tell me what's changed and how.
2) do tell me why you're doing it, specially if you aren't using a standard way - so I don't try to apply it and screw your elegant workaround (and tell around what was the workaround)
3) IOW, tell me what's not obvious. No rants. No emotional outbursts this way or other.
(actually, #3 is mine, but if Rox comes around, she's got a couple of beers for the first two)
Also, my rule of thumb is to have an intellisense script to have a "* [yyyy-mm-dd hh:mm:ss] {me} - " prefixed and signed comments, so not only I know what I (or someone else) did, but also when, so if some change is under doubt, we know its age, and whether it was before The Big Thing That We Did On That Other Piece or not. Maybe not crucial, but often helps. Also, part of the housekeeping is to purge obsolete comments - comments about parts of code which are commented out in the last ten versions, or about deleted lines of code, i.e. those which may cause more confusion than benefit.
Having chameleon programmers on the team also helps. The guys who can emulate any style without losing half their skillset. Then you can be somewhat sure that the additions in the production version won't be drastically incompatible with the project version. Not easy, but if you can sidestep the worst dependencies, enhance the production version with minimal intervention in the code, you're "on the horse" (an appropriate Serbian proverb, meaning "Good For You" - capitalization is a way to bring the "now we're in business" feel).
