4

The company I work for uses Clearcase, even though it was EOL'd on the platforms in which we run it years ago. It is ancient and fragile tech, but one thing it does have is a multisite support that allows for the synchronization of air-gapped repos. Because of security issues, we use secure USB sticks to copy packets and take them to the other side, then apply them with scripts.

Developers and DevOps people want to make a business case to migrate to GitLab, but I cannot find any mention of a feature in GitLab that would allow me to do easily do this. There's something about bundles, but the info I have found is years old and it doesn't seem like too many people are using it.

Does GitLab not support this? Simple synchronization of one repo to another over an air gap using some sort of secure media? If so, it's no wonder so many teams are still using ClearCase.

Juan Jimenez
  • 443
  • 4
  • 18
  • 1
    Actually, one of the key drivers outside of organizational inertia is the fine-grained build auditing. If you need to know EXACTLY what went into building a given executable, ClearCase can give you that. And as far as I can tell, nothing else comes close in that department. "Fragile" is a matter of perception, and if you're dealing with older unsupported platforms, it's hard to argue with that. If you still have to build for Solaris 8, for example, then any solution to do that with CC is going to be a bit wonky. – Brian Cowan Sep 16 '22 at 19:52
  • @BrianCowan The only thing this tells me is that you don't know GitLab and its CI/CD capabilities. That CC is fragile is not perception, it is first-hand experience. Multisite causes random oplog gap errors *all* the time, and it isn't exactly intuitive how to fix them, and that's just one of the problems. It's pretty much one heck of a kludge on top of an EOL product. – Juan Jimenez Sep 17 '22 at 23:50
  • 1
    I think you are confusing build logging with auditing. A fine-grained build audit includes literally everything that was **accessed** during a build, which may or may not show up in the build logs, which are based on the output of the build. To give you an idea what I'm talking about, this is the detailed build audit of the classic "hello world" C application when the build tools are under source control: https://pastebin.com/rMtGWgxU – Brian Cowan Sep 20 '22 at 14:51
  • 1
    If you're experiencing MS issues on a repetitive basis, are you entering support cases? Because I need to know about issues like that. If it's mkbranch oplogs, then I *really* want to know about it. – Brian Cowan Sep 20 '22 at 14:51
  • Support cases? LOL! We tried to ask IBM what to do about updating vob hosts across air-gapped multisites that are being migrated and we got a blank stare. It took us weeks to figure it out on our own. Migrating complex multisite setups in Clearcase is a nightmare. – Juan Jimenez Oct 26 '22 at 16:47
  • Were you the customer doing one way replication with self mastering replicas? This means that you couldn't change host names of the remote replicas from the central site. That is painful. You would need a support tool that edits the database to forcibly reset mastership. Alternatively, DNS aliases and the alternate_hostnames file can be used. Love to know who you were talking to, and any case numbers so I can review and critique the cases – Brian Cowan Oct 28 '22 at 13:12

1 Answers1

4

While not exactly easy, air-gap updates of Git repository is possible through the git bundle command.

It produces one file (with all the history, or only the latest commits for an incremental update), that you can:

  • copy and distribute easily (it is just one file after all)
  • clone or pull from(!)

This is not tied to GitLab, and can be applied to any Git repository.

From there, I have written before on migration from ClearCase to Git, and I usually:

  • do not import the full history, only major labels or UCM baselines
  • split VObs per project, each project being one Git repository
  • revisit what was versioned in Vobs: some large files/binaries might need to be .gitignore'd in the new Git repository.

You would not "migrate views": they are just workspace (be it static or dynamic). A simple clone of a repository is enough to recreate such a workspace (static here).

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • This is the info I was looking for. Now I have to find the other pieces of the puzzle, such as how to migrate VOBs, views, etc. – Juan Jimenez Aug 07 '22 at 00:08
  • 1
    @JuanJimenez I have edited the answer to address the migration part of your comment. – VonC Aug 07 '22 at 08:00