[Tutor] How to use Git from Windows PC for files on Solaris machine where Git cannot be installed?

boB Stepp robertvstepp at gmail.com
Thu Apr 30 06:28:59 CEST 2015


On Wed, Apr 29, 2015 at 10:39 PM, Cameron Simpson <cs at zip.com.au> wrote:
> On 29Apr2015 22:10, boB Stepp <robertvstepp at gmail.com> wrote:

>> On the smart enterprise where we (now) do our clinical planning they
>> are very strict: no installing any external software; no accessing the
>> Internet; no email; etc. Not all centers adhere to this level of
>> strictness, but ours does. [...] But I am reluctant to do
>> anything that I am not allowed to replicate on smart enterprise. I am
>> trying to keep it as close to identical to the actual clinical
>> environment as I can.
>
>
> And fair enough too. I frequently wish our developers' dev environments more
> rigorously modelled the target environment.
>
>> Perhaps this is misguided on my part?
>
>
> Not necessarily.
>
> But I would be inclined to distinguish your working tools from the target
> environment.
>
> For example, I commend you making your dev environment as close to identical
> to the actual clinical environment as you can. But I wouldn't deprive
> yourself of tools that enhance your code management practices without
> affecting that environment.
>
> For example, there is much to be said for tracking your changes with a tool
> like git or hg. It encourages your to annotate your changes, and lets you
> review history to see when and why some change occurred, especially if a new
> bug has arisen. Distributed version control systems like git and hg also
> make it easier to work on distinct changes to the same code as separate work
> processes; of course the price for such a workflow is that you need to merge
> the two things later and ensure that they do not interact badly.

Totally, totally convinced of the correctness of this. Actively
working to implement this. See below.

> If you're serious about keeping the two environments very similar, you could
> always do your _coding_ on a third platform (a laptop or whatever) using
> your desired tools and _deploy_ the code to the dev (and later, prod)
> environments from there, keeping the dev environment pristine. By "deploy",
> that can be as simple as copying the code to the target.

That is what I have implemented as of today. I installed Git on my
Windows PC where I have been doing my actual coding anyway, created
the needed repositories, including an extra one on our intranet in
case my PC dies, etc. The current project is now in version control.
After doing some editing and saving, I use the Git bash shell that
came with Git and scp the file(s) to the dev environment, do my
testing (Still manual; working on getting automated, but this will
have more of a learning curve for me than using Git.), etc. When I get
a meaningful chunk of something done, I add and commit in Git on the
Windows PC. Less often I push to the intranet repo. Your comments
suggest that I am on a reasonable track.

The main danger as I see it is that if I am not careful, then the code
on the dev environment could diverge from the state of code on my
Windows PC, i.e., I forgot to do the scp part. But when I am actively
working on a section of code I always insert a few print statements
(Py 2.4!) to verify I am getting what I should when I test it
out--even if I don't have an actual problem yet. And so far this has
immediately revealed those few instances so far when I forgot to save
to the dev machine (Usually when someone has interrupted my workflow,
a near constant occurrence at work.).


-- 
boB


More information about the Tutor mailing list