0

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:

  • Works on Windows 7.
    • Ideally this means it's usable in the Git bash or Cygwin but GUI solutions are acceptable, too.
  • Minimal/no configuration (i.e. a turnkey solution or something which only needs me to point it at the correct directory).
    • Assume some proficiency with Git, Cygwin, and Surround and that all three are already installed.
    • I've got a lot of latitude to install whatever I need, considering it's a company computer.
  • Is preferably well-documented.

Use Cases:

  • Use Git to manage parallel bug fixes and feature implementations.
    • If I commit changes to Git Master I'd like them to be checked in to the SCM repo.
    • If I merge a branch to Git Master, I'd like SCM to see those changes and stage them for check in.
    • If I create a branch off of Master, I don't want it to create a corresponding branch in SCM: at least not automatically. It could be nice if that was an option but it's definitely not required.

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.

Community
  • 1
  • 1
Jason
  • 372
  • 1
  • 4
  • 14
  • Could SourceTree + the gitflow plugin help you to do that ? – Franck Oct 29 '14 at 20:59
  • @Franck I just installed SourceTree and started looking in to git-flow. This isn't what I was hoping for, though git-flow is interesting and I'll look into adding that to my toolbox for future use. – Jason Oct 30 '14 at 13:13

1 Answers1

2

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.

Jason
  • 372
  • 1
  • 4
  • 14