Catching up a little here. Boy, these conversations can move quickly on weekends!
In your first message, the part "Tell everyone that they should not modify the central tree" really scares (and annoys) me. Generally, the only operations where you should tell people not to check things in are maintenance operations that affect the repository directly. For your "thousand files in a single directory" issue, you could use the -d option in the CVS/modules file to specify that the project should be checked out into a directory named enu. That would eliminate you having to use the -d option each time you check out a project. The modules file might look something like: wordpad -s dev -d enu path/in/repository For your basic procedures, I would suggest something like this: - apply a tag to the files you're going to take on-site - 'CVS export' those files - On-site, use 'cvs import' to import them to the local repository. - modify, check-in, etc. to your heart's content - when done, take a copy of the modified local repository files (*,v) back to your office - write or find a script or tool that will pull out the changes you've done on-site, and apply them to the local repository, on a branch created from the tag in step (1) - merge changes from the branch to the head On subsequent visits, you can re-import the latest version of the repository, and merge any changes made locally. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) _______________________________________________ Info-cvs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/info-cvs
