>Well, we have poured over the MSN article, and experimented a little. When we unpin a program in the development copy, and then make a modification in it, the modification still is reflected in the production copy of the project. That program is pinned in the production copy. We just end up with a new version of the modified program in the production copy.
>
>We don't want the changes to flow back and forth like that. We want changes in development to NOT show up in production. Changes in production (God forbid!) to fix some future bug SHOULD flow down to development. And after an afternoon of experimentation, we're a bit confused. Any tips?
>
>Marie

I'm sure you realize that you are "going against the grain" with this "requirement", but I do think it's worth emphasizing that every time one changes PRODUCTION code first - emergency or not - you are surely asking for serious trouble.
In fact I'd say that any good source control system would be deliberately designed to prevent this.

Putting new (even "emergency") code into PRODUCTION the way you describe you wish strongly suggests that you have NOT TESTED that code - if you had then you would be able to move it in the "proper way".

It may make sense now BUT you should AVOID UNTESTED PRODUCTION UPDATES at all costs!

I'm pretty sure that there's a way to ram 'emergency changes' up the hierarchy with VSS or other source control products (my experience is limited to 1 small project where this never came up) but going the other way really is BAD.

Regards
JimN