I've applied two approaches to address this problem that can be implemented readily with CVS:
The first method is to use a personal branch for your own development and periodically merge to the main branch. This is a standard pattern of use in CVS. The second is to divorce the notion of "committed code" from "good code", allowing the developers to commit at will. Then have a mechanism to identify the good code and only use that outside the developer's workspace. This can be crudely implemented with tags, but I used changesets implemented with the submit/assemble method that has been discussed in this forum several times in the past. --- Forwarded mail from [EMAIL PROTECTED] I work onsite about half the time and offsite the other half. Some nights, I'll be onsite, be half way through a complex set of changes, have heaps of modified files, and have to go home. The next morning, I want to pick up from where I left off, but this time from home. I can't commit the stuff at work (at least to the head branch), because it's not stable enough (may not even build). I'm currently using a shell script cludge that scp's the modified and new files over to my home PC, and then I have to remember to do the oposite before going back onsite. --- End of forwarded message from [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs