Ignoring for a moment the wisdom of manipulating the source code, ask yourself how this watermark should work. You need to have different files for every developer. This means some automated code transformation that doesn't change the meaning of the code, yet isn't reversible. Oh, and it shouldn't make the code difficult to maintain. At the end of the day, it's supposed to be valuable code, right?
Add whitespace? That can be trivially normalized. Change variable names? You mean obfuscate the source code in your own source tree?
And if the watermark ever fails: “Hey, you broke the build!” “On your checkout, maybe. Works for me.”
Next, think about it: you need to have different files for every developer. Collaborate on hunting down a bug? “I tracked the problem in the debugger,
x isn't initialized.” “What
x? I only have
z in my copy.”
Even if you somehow found a way to watermark the source code, this can only be useful if developers have no alternate way of obtaining the source code. So having the build server produce a source archive is right out. That's not a show-stopper, but you are walking a thin line.
Now let's think for a minute about the wisdom of this approach. You're telling the developers that you trust them to write code (and not to do a shoddy job, or plant backdoors), but you don't trust them not to leak the code. First, this position looks pretty inconsistent, so it's not going to go down well with your typical developer. Second, you're making their job more difficult (see above) for no tangible benefit. Again, that's not going to be popular. The predictable end result is that your developers will take one look at your coding methods, and go and contribute their ideas to the competition, and leave you with your shoddy code.
Even if by some miracle you were able to implement a watermark system, how useful do you think it could be? If Alice's version of the source code is leaked, how do you know Alice leaked it? If Eve wants to leak the code, assuming she cannot get rid of her watermark or change it to Alice's, she can disguise her tracks by leaking Alice's code. She might access Alice's machine surreptitiously — so you need to encrypt all drives, train your developers against evil maid attacks, have stringent policies of not sharing editor macros or uncommitted patches… While some of these are good high-security measures, to block all attack paths, you also have to severely limit team efficiency.
If you have a significant body of code, what you can do is limit the access to the source code, so that each team only sees the modules it's working on. For large enough code bases, this is in fact good hygiene as it maintains independence between components. If restricting access to parts of the source code isn't working for you, you don't have nearly enough code or you don't need nearly enough confidentiality to even consider this watermarking scheme.