Jon Brisbin <jon.brisbin@xxxxxxxxxxxxxxxxxxxx> wrote: > > I'm just wondering what the Git experts would say to someone wanting to > transition from say, Visual SourceSafe, and expecting the predictability > of having source files "locked out" while a developer is making changes > to them? I had a really hard time with this "locked out" mentality at my last employer. They used PVCS Version Manager, and relied heavily on its "lock out" feature to protect files while they were being edited. But more often than not, what happened was a guy had a file locked for a month at a time while doing some new feature change, he'd go on vacation for a week, and a production issue would crop up that need a fix in that file. Half of the time, developers would try to fix the code somewhere else. They realized that was bad, e.g. putting in 85 if-then tests at every call site because a function didn't tolerate a bad input, but if they could lock the other 85 files, they'd do it over trying to break the lock held by the first guy. It took me a year to convince them that git's no-lock model is better. But they finally came over. Most of it was about the fact that they could now finally avoid that lock problem, and just do the right change, and not need to do work arounds. One of the guys had trouble with that, he was OK with doing work arounds instead of real fixes, but once we cleaned up most of his workarounds and the code base practically got cut in half, he got on board. Its an uphill battle. -- Shawn. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html