Any thoughts on Surround scm?

Question

So looking at different version control systems: subversion, accurev, surround, tfs, bitkeeper/git/mercurial

• Subversion: I see it's quite the popular standard
• Accurev: There seems to be a love hate relationship around it.
• Surround and TFS: I haven't seen many comments around them.
• Bitkeeper/Git/Mercurial: Seem pretty popular, but I think "distributed" may scare my manager lol

For some reason he seems attracted to Surround and it's not because of sales pitch. We had originally downloaded it for evaluation played around with it but nothing came of it. So now we are back to looking at scm and wants to try it again. So far I haven't seen any buzz around it like some other version control systems. Same for TFS

Answer 1

I've been using Surround SCM at my job and I'll say it is what it is, but there are a few things that I find lacking. Though, I've heard that surround scm integrates well with surround's issue tracking system, but I can't comment on that because we don't use that.

I personally find the UI to be buggy and confusing.

• The workflows are confusing and often offer you with prompts that don't apply, so you get used to ignoring warnings.
  • eg. "are you sure you don't want to auto-merge?" "Are you sure you want to overwrite files?"
• The UI always badgers you to use the auto-merge feature but every time I've tried it, it ends up messing up my code (C#).
• On top of that, the packaged diff tool (Guiffy) is buggy and doesn't display text properly.
• Weird workflow quirks can result in your changes being overwritten.

It doesn't do directory syncing ...which means that every time you add a new file to your project you must by-hand go and add it to the SCM repository. If you don't, everything will look normal to you until one of your teammates emails you because you broke the build.

There's no good way to copy over revision histories when you are branching ... which means that you are less likely to branch when you should be. There's nothing more frustrating than to have to store code locally because you're making changes right before a release and your team refuses to branch the code into another repository.

There's no good way to blacklist certain files from being checked-in or from being overwritten during an update. If there's a file that you don't want to check-in then you're left with the painful chore of scanning through a long list of files and deselecting those you don't want every time you want to check-in. Yuck.

Features aren't documented that well Of course, they release a user's guide but it's about as helpful as Microsoft Windows help function. It tells you step by step how to do things in the UI (ie. "click 'Create Shadow Directory', then click 'OK'", but it doesn't tell you what those features are, how they are intended to be used, what actually happens server-side etc.

Btw, if you know of any good way to get around these problems let me know :)

Answer 2

Danger! Danger, Will Robinson!

Surround is a data jail. Once you commit to it, you're stuck. There is no known way to get your history back out to another SCM. Don't get trapped!

This tends to be a problem with closed-source SCMs in general, but I have direct reports that it's especially bad with Surround.

Subversion, git, Mercurial, or Bazaar would be better choices.

Answer 3

I have used Surround at my job for about three years.

It does work well with their (Seapine's) test management and issue tracker program. If you are already using TestTrack, I would say Surround is a good choice.

In general I agree with @eremzeit, but the 'buggy and confusing' comment rarely applies to our workflow. The default diff tool (Guiffy) is bad, but often good enough.

One part I like is the easy ability to share files across repositories without needing to share a whole project/repository. Git does not have a mechanism to do this easily.

Last note: we have used Surround on Linux and Windows and it appears to work just as well on either. It is nice to have the same interface.

Answer 4

Surround SCM.

Pros:

• Can apply a development work flow for all files. No two revisions of a file can be in the same status in the work flow.
• Has a good UI.
• Good licensing system.

Cons:

• Stores all data in a RDBMS.. heading for a performance problem if the repo size is huge.
• Does not support atomic commits. (you can do atomic commits but the files are still revisions and cannot be refereed using the changelist #)

---

My ideas about other tools

Subversion suits well for a corporate setup. Perforce is like subversion but faster and has a good UI, simple licensing terms and really super support system. Recently Accurev has gained a strong footing with its innovative branching methodology.

IMHO. go for tool sets that interact well with your defect tracking, test case management and build management solution. This would help you create a good developer ecosystem thereby saving time.