From: Brian Leach > ...The key was to appoint someone who was responsible for it. > If it is anything more than trivial, it needs someone charged > to administer it,
Conan the Librarian > not just left to the whims of developers!... Which brings us to the 2nd key: Build in perks for the developers for using version control. It shouldn't be another layer of management that slows them down. Properly implemented, it should be a programmer productivity tool. The more that it helps them be able to compare versions, track what change happened when & by whom, lump & segregate work, coordinate activity between programmers, do status reporting . . ., the more it directly helps programmers do those tasks, the more enthusiastic they will be, & the less likely to circumvent or resent enforcement. I recall implementing it one time where the practice had been to never delete old code, just comment it out and surround changes with date and project numbers comment lines. It got so that a source file had more commented out stuff than actual compilable code. Very difficult to read. When we implemented version control, I suggested that this practice was no longer necessary because they could easily reconstruct pretty pictures of change history. They insisted on doing it the old way, too. Several months later the staff violently revolted against their own conservatism and wanted a special internal project just to clean out all that old stuff because version control was so good to them. ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
