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

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

[Jon Brisbin]

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.

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

[Shawn O. Pearce]

Jon Brisbin <jon.brisbin@npcinternational.com> 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.

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

[Heiko Voigt]

On Tue, May 12, 2009 at 10:42:32AM -0500, Jon Brisbin 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?

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

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

[Andreas Ericsson]

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@op5.se
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.

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

[Mike Ralphson]

2009/5/12 Andreas Ericsson <ae@op5.se>:
> 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.

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

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

[Mike Ralphson]

2009/5/12 Jon Brisbin <jon.brisbin@npcinternational.com>:
> 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.

+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

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

[Jon Brisbin]

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:

> 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?

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

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

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.

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

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 devs expect their changes to go live at midnight after they
> 'release' them. Are there similar assumptions for you?

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.

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

[Magnus Bäck]

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

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

[...]

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

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?

[...]

-- 
Magnus Bäck
baeck@swipnet.se

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

[Jon Brisbin]

On May 12, 2009, at 1:13 PM, Magnus Bäck 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?

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.

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

[Ealdwulf Wuffinga]

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

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

[dleong]

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.

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

[Randall S. Becker]

On December-02-15 1:10 PM dleong wrote:
>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.

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.