How to move users from SEU (AS400) to Git?

Folks,

Our development manager was evaluating transitioning our AS400 department to IBM Rational for the RPG programmers, who currently use SEU for all their editing and source code control. I was asked about CVS and how it compared to what they're doing now (so they wouldn't have to pay quite as much by omitting the source code control part of Rational) and I explained why the Java programmers don't use CVS. We're transitioning from Subversion to Git at the moment and I tried to explain how the paradigm of managing source code using Git was different than what they were used to.

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.

How do I argue that a more open, Git-based approach to development is "better" than the traditional, SEU-based methodology they use today? 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. Since Rational is eclipse-based, I'm assuming the Git plugin for eclipse would work with Rational, but I'm on a Mac so I have no way to test this.

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?

Thanks!

Jon Brisbin Portal Webmaster NPC International, Inc.

Jon Brisbin <jon.brisbin@npcinternational.com> wrote:

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.

On Tue, May 12, 2009 at 10:42:32AM -0500, Jon Brisbin wrote:

How about this:

With Git you effectively get a *local lock* on *all files*. These locks are just called branches. Thus you do not have to worry about anything getting lost (like it could happen with the svn/cvs update command).

To unlock you merge. If you merge two branches and something (although unlikely) goes wrong you can always return to the "different locked states" and investigate.

Seen this way git is the best from both worlds (lock/merge).

cheers Heiko

Jon Brisbin wrote:

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).

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.

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'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.

2009/5/12 Andreas Ericsson <ae@op5.se>:

To indicate what's being worked on, both within and outside our traditional pessimistic locking strategy, we simply push lightweight tags to the central repo.

It allows us to see who's got what locked (and since when), but it also allows us to do file-level three-way merges if necessary so we can keep long-running / speculative development up-to-date. The poor-man's rebase does the patch and moves the source tag along. Releasing the lock removes the tag.

Mike

2009/5/12 Jon Brisbin <jon.brisbin@npcinternational.com>:

+1 everything Shawn and Andreas said, but there are other practical issues beyond developer mindset.

(see http://article.gmane.org/gmane.comp.version-control.git/117755 for my context)

I'm not familiar with the AS400 or SEU but do developers currently have a complete copy of the tree to themselves, or do they only check out the files they're editing?

I'm not sure what Rational Developer is likely to want to do in terms of getting the edited files back to the AS400 (assuming it supports that directly). Are you planning to run (j)git on the AS400 or have another step to get the code from a central git repo back to the AS400(s)?

Is any deployment done to a test server? Is there a release process you need to integrate with?

Our devs expect their changes to go live at midnight after they 'release' them. Are there similar assumptions for you?

They also expect to see everyone else's changes (to all the source files they're *not* working on) as soon as they go live, without having to pull them. Madness, sure, but it's the kind of madness they happen to want.

Previously, no-one would have had to worry about merging / integrating (unless locks were broken). Someone (possibly everyone) now has to do this.

Unless developers have an AS400 at home, or a very funky emulator on their laptop, many of the distributed benefits of git are probably going to be of no use to you.

You probably need to address what concrete benefits remain and see if you *want* to try and sell them.

Local / feature branches, ease of moving work and history between developers, speed, repository size, repository resilience, usable tags, immutable history... All of those might still apply as wins in a centralised / minimal-merging environment.

You may also want to find out if IBM can point you at a reference site for Clearcase (presumably?) on the AS400 in conjunction with Rational Developer on pcs. It may be so bad and so different to what they have now, that you can push git (with a bit of scripting around it) as actually more similar to their current workflow. 8-)

Mike

First, thanks everyone for the cogent responses. After a big salad and some chicken enchilada soup, I'm now energized to tackle this problem with renewed vigor... :)

On May 12, 2009, at 11:40 AM, Mike Ralphson wrote:

They only check out the specific files they need, unfortunately.

Since I work with, but am not a part of, the AS400 group, I don't have a copy of Rational to play with. I have used Websphere Studio before, though (which I think is the precursor to Rational/eclipse) and it used the toolbox utilities (JT400 et al) to transfer files locally, allow the developer to work on the file, then put them back on the server where they can be compiled. I would assume Rational works similarly. This is making me wonder whether any open source scm will work for this scenario. We may be tied to IBM's tools or nothing.

We have a test/release cycle that the AS400 group calls "implementation" that is basically copying stuff from a development 400 to the production 400. I'm not sure what role an alternative scm would play in this scenario. There's also a fantastically cumbersome reverse implementation process called a "refresh", which copies data files from production back to development and basically clobbers whatever is on development. Only developer libraries are left untouched. This seems to me to be a process which could, shall we say, use some improvement. :)

Our deployments have to go through some SOX-compliance ring-around-the- rosie, so they don't really have any assumptions as to when changes are pushed to production. I could see hook scripts filling doing some of the work here. But some manual intervention will be required for compliance reasons.

Thanks!

Jon Brisbin Portal Webmaster NPC International, Inc.

On Tuesday, May 12, 2009 at 19:56 CEST,
     Jon Brisbin <jon.brisbin@npcinternational.com> wrote:

[...]

I hope I'm not stating the obvious here, but "Rational" is a division within IBM, not a product. IBM Rational has two solutions for version control, ClearCase and Team Concert. The latter does a lot more than just version control though, and it seems to be shipped with Rational Developer. Just to be clear, which product(s) are they considering?

[...]

On May 12, 2009, at 1:13 PM, Magnus Bäck wrote:

Thanks for the clarification.

I think they were looking at Rational Developer/Team Concert. That name sounds familiar, at least.

Thanks!

Jon Brisbin Portal Webmaster NPC International, Inc.

First, I just have to say: There are still people writing RPG? OMG!

Secondly, I think you may need to think carefully about merging. Looking at the wikipedia entry, RPG is column oriented. Maybe existing merge tools will screw up the column structure. Even if they don't, they will probably screw up the alignment and make your users have to go back and fix it.

As far as advantages go, I would suggest going back to them and asking them 'what have you always wanted to change about SEU?' Maybe they don't actually like locking. Maybe they have some problem we haven't seen yet, but could easily fix.

There is some kind of RPG editor here which may be of interest: http://www.rpgnextgen.com/

Ealdwulf

I stumbled on this topic while doing a research on how to move RPG source control to adopt using Git. I wonder if the original question was answered. My company would love to have a more central system to maintain both RPG codes and javascript codes. We use Rational Developer exclusively (no more SEU) for our developers and we do not have budget to use Team Concert from IBM. So Git seems like a good solution.

Finally. There are still a lot of RPG programmers out there. If you have not checked lately, RPG is no longer a language with fix format column structure: http://www.ibm.com/developerworks/ibmi/library/i-ibmi-rpg-support/ <http://www.ibm.com/developerworks/ibmi/library/i-ibmi-rpg-support/>

-- View this message in context: http://git.661346.n2.nabble.com/How-to-move-users-from-SEU-AS400-to-Git-tp2870074p7643587.html Sent from the git mailing list archive at Nabble.com.

On December-02-15 1:10 PM dleong wrote:

codes >and javascript codes. We use Rational Developer exclusively (no more

IBM. >So Git seems like a good solution.

I don't see any reason why Git would not be happy with RPG, whether structured or not, providing you have a reasonably Posix-like file system. The Rational Suite includes ClearCase, which can also be converted to Git (BTDT), although it is a bit intricate to convert and the complexity depends entirely on what part of history you want to preserve.

Cheers, Randall -- NonStop and Unix geek since before the CSNet mass migration.