Help me help my colleague

January 8, 2012 4:06 AM

My colleague uses a Windows editor for writing code and a Unix system to run it. He has practical issues with version control. Suggestions?

Colleague (PhD student) is currently working on a large development task and I would like him to use version control (git) for 1) his own sanity and mine 2) so that the rest of the group is able to use/track his changes over time.

We are working in a research lab and I have a relationship halfway between "mentor" and "manager" with him. However we are both reporting to the same supervisor, who does not care about the issue at all. Our group uses "horizontal development" meaning that peer self-organization is expected and encouraged.


Longish circumstances below, TLDR at the end.

Current situation

The project involves a Unix-oriented C++ program, with (mostly) test-driven development. The code must thus be compiled and run on a Unixish system. We have a development server where colleague has a home directory and all dependent tools installed (by me). One "reference" copy of the source tree is hosted using git on another repository server on the network; other team members have local copies on their desktop and already have functional workflows.

His current setup is as follows:

A. he made once a repository checkout of the project in his Unix home directory.

B. he then made a copy of that checkout on his Windows desktop.

C. he edits and investigates code on his Windows desktop.

D. whenever he wants to test his code, he:

1. copies the modified files manually with a graphical SCP client for Windows (ie a: navigate with point-and-click to each directory with modified files, b: navigate with point-and-click to the same directory on the server, then c: find the modified files based on "modified" timestamp, then d: copy the files using drag-and-drop)
2. using a remote session in PuTTY, compile and test
3. for every error in the Unix terminal, go back to the Windows editor and investigate.

E. whenever he has to commit his code to the repository, he:

1. makes a new checkout of the latest version from the repository in his Unix homedir
2. runs "diff" between the new repository version and his Unix working dir
3. using the Windows editor, manually copies the changes from the diff file to each file in turn
4. tests as per D# above
5. then commit.

Needless say, the pain in #E means that commits happen seldom, if ever. Also, lack of a proper backup solution on the Windows system means that he has no incremental vision of his work, and commits populate huge swaths of changes at once, which pose a large obstacle to understand his development steps.

Constraints

1. in our organization any Windows desktop must be centrally administrated by our IT department, which means we can't install 3rd party tools that require administrator rights to install. In contrast (and strangely) Mac and Linux desktops are not administered by IT and are under the sole responsibility of the user.
2. Said colleague has freshly graduated from China:
   • he suffers from a perceptible lack of initiative-taking about the problem, which I attribute to his experience in China restricted to vertical work hierarchies exclusively. Note that he does take initiative about writing code, just not about anything related to version control and his strange windows-unix workflow.
   • the Windows box is heavily Chinese-customized; he is used to (and uses) the Chinese input methods. He also uses all kinds of Chinese-speaking Windows-specific software: chat clients, translators, and other things I don't understand.
3. 
   our research group has always been flexible as to work environments, meaning there were no hard "must do" or "don't" with regards to tools, desktop setup, etc. It is assumed that all members have appropriate skills to set up their environment. Therefore it would be difficult to mandate a specific work environment to my colleague unless it is mandated to everyone else, which everyone else but him would loathe.
   

Questions

A. as a starting point, how can I smooth his workflow? For example:

• is there some form of git client for Windows that 1) he could integrate in his workflow and 2) that does not require admin rights to install?
• are there other synchronization facilities that would make his testing cycle simpler?

B. are there any Chinese language documentation / resources to 1) explain the problems that version control solves 2) introduce the use of distributed version control to newcomers?

C. assuming the computer is powerful enough, what combination of host OS and virtual machines would you suggest to create a work environment that he could run entirely on his desktop?

-- TL;DR --

Chinese colleague without software engineering background edits on Windows, and manually copies code on Unix to compile, test, and commit to git. Workflow is terribly inefficient, impossible to track his changes in git over time.
How to transcend the cultural and experience issues to improve his work environment?

posted by knz to computers & internet (12 answers total)

You can get a portable git runtime here. It shouldn't require admin rights, although I've never used it so I'm not 100% certain on that. Depending on your powershell config, something like posh git may also be viable.
posted by feloniousmonk at 4:30 AM on January 8

The problem seems to be that he is not actually using git while he works, only at the stage where he needs to push changes to everybody else, so it's difficult for anybody else to see what he's doing.

If he commited his changes when he's done editing and then let git do the work of copying between windows/unix then you would be able to see simple atomic commits instead.

My suggestion would be to have him maintain two git repositories as he works, separate from the central repository. One on windows and one in his home directory on the unix system.

Set up the remotes so he can easily push/pull between each repository.

The workflow could be something like this:

1. When he wants to make a change on his windows machine, pull all the commits from the central repo so he is up to date.
2. When he's done, commit the change and push the commit to his unix repo
3. Log on to unix and test the changes. Make any fixes and commit them. These can be amended to the previous commit with "git commit --amend", or he can just do a separate commit.

When he wants to commit the central repository he would push all his commits from his unix repository. He will need to learn how to handle merging and resolving conflicts, but this isn't really much different to what he's doing now in step E, except git will identify the conflicts automatically.
posted by Unexpected Indent at 5:17 AM on January 8 [2 favorites]

Perhaps you could setup Samba on the Unix system, so he could edit the files in his Unix home directory from his Windows system? This way he needs only one personal repo, which would simplify teaching him how to use git properly.

Another thing to consider is that he might not be able to use Unix very well. From step D3, it seems like he might not know how to edit his source code on the Unix system.
posted by reynaert at 6:10 AM on January 8

As a matter of interest, what's a more typical development process for the team? For instance, what's yours?
posted by ManyLeggedCreature at 6:31 AM on January 8

@ManyLeggedCreature: other team members use a GNU/Linux desktop with all kinds of grpahical text editors and a command line interface to git; one uses a Windows desktop but works entirely remotely on the server via a ssh client. I am somewhat an exception, as I work locally on OS X but using a full screen Terminal with tmux/screen and emacs inside.

For the rest of us (ie not this colleague), the text editor, the test environment and the git client are running on the same system.
posted by knz at 6:43 AM on January 8

This is just a hack and not the solution that you're looking for, but does he know about winscp? scp freeware, will let him edit files on the unix server from his windows machine, without having to do the file trasnfer himself (files get saved on the server over ssh as soon as he hits ctrl+s)
posted by 3mendo at 6:48 AM on January 8

Like reynaert said, Samba. If you're on a LAN so that network mounts are speedy. I do that in reverse edit, etc. on Linux, test on Windows. If Samba isn't an option then at least try to find a rsync-like client for Windows that will copy changed files up/down with a single command, and then wrap that up in a .bat file or something. On Unix side: git pull, on Windows side: sync-down. Edit. Windows side: sync-up, Unix side: test, git add, git commit. Maybe just making the copy changes up/down less painful would go a long way to more frequent commits.
posted by zengargoyle at 7:04 AM on January 8

There also seems to be a sshfs client for Windows. This would be simpler than setting up Samba and work about the same (with a bit of a hit from the ssh part).
posted by zengargoyle at 7:14 AM on January 8 [1 favorite]

Samba would work. But you've already got someone using the solution I'd be leaning towards: keep the Windows desktop for web access, IM conversations, easy Chinese input and so on and so forth, but use ssh in order to develop, test and commit on the server directly. Have you ruled that out for a reason? (Sorry if I've missed something.)

It sounds as if he might take some persuading - and, like reynaert, I would guess that he needs some help getting used to Unix - but hopefully he'd appreciate the massively simplified workflow. Bonus: no line ending issues (or does git take care of those for you?).
posted by ManyLeggedCreature at 7:20 AM on January 8

Creating a repo on his PC would be the best option if he could test there, but since he can't it would make him commit and push every tiny change which no developer would enjoy.

As a third option similar to Samba and sshfs, is there an SFTP client for Windows that does what Transmit does on the Mac? Transmit will transparently copy a file to a temp file on the local machine, open it in whatever editor you associate with its extension, then sync changes to the server on each save.
posted by nicwolff at 7:26 AM on January 8

Yeesh. You know, Vagrant lets you set up VMs that network share onto the host OS pretty easily.
posted by Leon at 2:11 PM on January 8

So the solution we settled on was:

- working dir with editor and git client on windows

- synchronization with the unix box using Unison

Next we'll look at mounting the unix home dir on the windows box. Since we don't administrate the unix server, it will depends on whether the IT administration has something already.

Thanks to all!
posted by knz at 7:52 AM on January 9