Jon Brisbin wrote:
Today, an RPG programmer can "check out" a source member and SEU won't let anyone else check that same member out (and it tells the developer who has it locked). The C++ programmers here also use Visual SourceSafe, with this same setting turned on. They are open to shifting paradigms away from this development methodology (the "I'm working on this source file and I don't want anyone else changing it until I'm done") but keep in mind that AS400 programmers are NOT cutting-edge and don't keep up with the latest development trends. Since we're not going to fire every RPG developer we have, we need an upgrade or transition path away from the SEU mindset to a more laissez-faire development approach like that encouraged by using Git. But one of the first roadblocks is going to be this notion that someone else can work on the same file I'm working on and that this lack of control invites errors and introduces unnecessary complexity.
At $dayjob, we do daily standups at the start of each day. Each developer speaks for a maximum of two minutes of what they intend to work on that day. This prevents double-work and usually causes 2-man teams to form spontaneously when two developers need something changed in either the same or conflicting ways. This way, conflicts rarely happen and when they do crop up, developers don't even have to watch git to find out who wrote the changes that conflicted with them (although some will learn to do that very quickly).
How do I argue that a more open, Git-based approach to development is "better" than the traditional, SEU-based methodology they use today?
Tough one. It might not be, even. If what they do now "just works", I expect many of them will consider it useless toolchurn just for the hype of it. Old programmers rarely enjoy that sort of thing.
It may be an "old" way of doing things, but SEU works for them and, more importantly, they can understand the process. We don't share any of our source code outside our organization and no one who would potentially work on the source code is farther than a cubicle or two away, so our needs in no way extend to what OpenSource projects require, with their large and distributed developer base. Using Git seems so open that its difficult to explain and even more difficult to defend against traditions that are 20 years old and have an entire industry of momentum behind them.
Well, lots of communication is easier to achieve in a small team than in a large one, so try to get the people talking to each other. The only trouble we have at my workplace is when conflicts crop up. They will do that at your place too, and when they do it's likely they'll need some help resolving them. However, communication and the mantra "useless codechurn is useless" will assist you quite neatly there.
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'd say: Hey, coders. If you want locking, we can write a small tool for that. To make it a learning process too, that tool will be versioned by git. We need a small (and stupid) server and a small (and stupid) client. Locking will be advisory, so you can stick to it if you like, and you get a nice reason to yell at whoever ignored your lock in case of conflicts. But that's just me, I guess. I've actually wanted such a tool as a sort of "I'm working from home on *this* and *this*", but haven't been able to muster the energy to work on it, especially since most of us where I work are reasonably comfortable in the face of merge-conflicts. -- Andreas Ericsson andreas.ericsson@xxxxxx OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Register now for Nordic Meet on Nagios, June 3-4 in Stockholm http://nordicmeetonnagios.op5.org/ Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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