I think I have expressed myself badly. Our developers are working on both windows and linux -at the same time-. Either with 2 dev boxes, or using VMware to run the other OS, with a partition shared between the 2. What is being suggested here is using commit to propogate changes between a given developer's OS-specific sandboxes during development. I am talking here about 'ok that fix builds under windows, lets see if builds under linux'. In our case right now this class of commit would not be done, and I can't see how this won't lead to an increased risk of nonsense in the repository. Maybe I'm splitting hairs but even if the risk is small it just doesn't seem a good idea. I can't believe our situation is all that rare.
You might consider using branches. Make the commits on the branches, test, then if everything works correctly you can merge to the trunk. That way, the trunk has a high probability of not being broken.
Yes, this has more steps. However, you are working in a more complicated environment than usual so you shouldn't be surprised by extra complexity in the development process.
Fred
_______________________________________________________________ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/
_______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
