2

Because of security restrictions, I have an environment with 2 Windows PCs which are basically air-gapped - ie not connected to any network.

Both PCs will develop some code, which is a shared development between them. The only mechanism for sharing this between the 2 PCs is via an encrypted external drive, which will only be used for that purpose.

I want to have some form of version control which will allow the version-controlled files/VC archives to be exchanged between the machines so that each machine can work on any part of the shared code base.

I can accept limitations that we will have to "manually" avoid working on the same code (the machines/users are co-located), as the VC software won't have any knowledge of locks / changes happening on the other machine

What are my options? GIT looks like it might work for this, treating the external drive as the master repository, and I could live with that though I'm not a great fan of, nor very experienced with, GIT (all my VC history is with PCVS (mostly) and SCCS). Is there anything better/simpler than GIT that would work in this scenario?

0

2 Answers 2

2

Git is a very powerful tool that would work perfectly for what you need.

Where i work, our network is standalone and we have a git server that we all work off.

Using the drive as a master version of the repository, along with a local copy on each machine would work just fine.

There is lots of documentation for GIT as it is widely used and can be installed offline easy onto your dev machines.

When you attach the external drive to the computer you can merge your local branch/version to it.

1
  • 1
    I think you're probably right - I need to just bite the bullet and get my head around Git
    – khafka
    Commented Feb 19, 2019 at 12:01
0

If you have reasons to consider avoiding git (perhaps more troubles when using it on Windows?), have a look at fossil.

A couple of appealing features out of my mind:

  1. comes from a notorious hacker as well (the author of sqlite)

  2. is actively developed

  3. a repository is a single file containing an sqlite database, which makes it trivial to move between different places

  4. it is a single binary

  5. has built-in wiki, tickets, web GUI, it's basically a micro GitHub/Gitlab/Gitea, except it uses something else than git

1
  • Thanks for this suggestion. Looking at the docs for Fossil, I don't think it's going to meet my need - unless I've totally misunderstood, I need a 'server' to manage the synchronising central repository which is communicated with over HTTP. In my situation, the developers will be air-gapped apart from an encryted USB drive. It would be possible to move the local repositories around and try to sync them on each machine, but this looks open to user error
    – khafka
    Commented Feb 19, 2019 at 12:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.