Jason
Jason

Reputation: 372

Use Git locally to manage code from a Surround SCM repo

I'm looking for a two-way bridge between Git and Seapine Surround SCM similar to git-tfs or git-svn. As I've been writing this, it occurs to me that this is a really tall order so I pretty well expect comments/answers that it's not really possible.

I found this question and I don't think it really covers what I want. I don't want to migrate away from Surround and I don't care if Git knows anything about the file histories in Surround.

My company uses Surround SCM which doesn't meet my needs. I've been using git in Cygwin to shuffle code around but Surround throws fits about switching Git branches under a single SCM repo. Usually, SCM tells me that I've modified some files after switching Git branches but, when I ask for a diff, it tells me the files are identical. It's been a serviceable solution but it's also apparent that it's not a very fluent solution in that Git and Surround don't actually talk to one another and aren't really fast friends.

I'm not 100% certain that the bridges I referenced above are perfect analogues for what I need. I've included my requirements and use cases below. If there is some other solution available that enables me to perform my use cases, I'm all ears.

We're going to switch to TFS (eventually) so I'm hoping for a relatively simple solution if one exists. I'm willing to put some time into researching and configuring stuff but I really don't know where to start. I've even got some bandwidth to write my own solution if anyone has tips on how to approach that.

Assume that I don't have permissions to do anything but check out existing repos and commit to them. I can't branch, create new repos, whatever.

Requirements:

Use Cases:

I'll leave the details at this, for now. I can expound on any of this stuff, though, if I haven't adequate explained my problems and how I'd like them to be fixed.

Upvotes: 0

Views: 787

Answers (1)

Jason
Jason

Reputation: 372

This is my experimental hacky solution. It isn't at all a two-way bridge but it allows me to handle my local workspaces using Git without disrupting Surround (so far).

To avoid upsetting Surround:

  • Initialize a Git repo in the Surround working directory.
    • Surround (at least the way it was set up by IT at my company) ignores the .git folder.
    • Add .MySCMServerInfo to .gitignore. Make sure the pattern looks in subdirectories: **/.MySCMServerInfo should do the trick.
  • Clone this new Git repo to a different physical location.
    • Any changes to this cloned repo can't be spotted by Surround so you can do whatever you want or need without Surround being the wiser for it.

Getting changes from local workspaces into the central Surround repo is the hacky part of this whole thing and I don't have the kinks worked out, yet.

  • Make sure your Surround working directory has latest from the repo.
  • Use Git to merge those changes into the cloned repo (i.e. the repo not tracked by Surround).
  • Resolve any merge conflicts as needed.
  • Commit the changes to your cloned repo.
  • Fetch the changes in the cloned repo to the original.
  • Check in changes in Surround.

This isn't elegant at all but it brings a lot of Git power to my local workspace while I wait for TFS.

Upvotes: 2

Related Questions