Doug Lee wrote: > Forgive me here please, but I understand neither what scares and > annoys you, nor what you suggest. The fact that you are relying on others to remember not to modify the repository scares me. The fact that you are telling people not to modify the repository annoys me.
Some of our developers used to send out emails saying "Don't modify the repository, I'm about to [whatever]." As I said in my earlier email, this is very annoying, because the "C" in "CVS" stands for "Concurrent" - if you have to tell everybody to stay out, that's not very concurrent :=). (Side note: I managed to drill into everyone's head the usefulness of tags for every situation where they previously thought they had to protect the repository from changes.) > But > while I'm working directly with the client, it makes little sense for > anyone else off site to check into that tree anyway, so there's never > been a problem there. Yet :=) Seriously, though, if you are the only person who modifies the files, then it may not be such a big deal. If it does become a big deal, there are ways to make sections of the repository read-only of course (the cvs_acls script comes to mind, for example). > A viable alternative indeed. Again though, since I don't expect local > (not at client site) commits while I'm at the client site, I don't > think I should need a branch for each visit. Well, on the off chance that someone does modify something while you're out, then I figured it would be easier to merge any changes if your on-site work was in a branch. A script that can handle that merging would be more complex than one that just plunks everything into a fresh branch, then does a single merge and exits, ready for you to resolve and check in any conflicts. Also, creating a branch has another advantage, in that you can keep track of which changes were done in the office, and which were done on-site. You never know when you might want or need that kind of information. -- 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
