Hello all,

Our team (10-12 developers, using WebFOCUS 7.7.01) had been running Microsoft Visual Source Safe for a couple of months, but discovered issues with the .SCC file becoming corrupted as well as repeated code loss. We've since disabled VSS while we investigated.

Since then, we discovered that our VSS server is located across the WAN in another datacenter, and at Microsoft's recommendation have created another VSS server physically located in the same datacenter as our development environment.

We've also been told that VSS doesn't support atomic commits, which can actually cause check ins to fail (or even partial check ins of a file), but not alert the developer that anything is wrong. We've been urged by Microsoft to upgrade to TFS 2008 or 2010 as they do support the atomic commit model.

However, Information Builders has informed us that they do not yet support TFS (probably not until 8.0 or revision after). However, I've seen at least one post of someone using TFS successfully with minimal errors.

The only other source control servers available to us in our organization are TFS 2008 and Vault. Any other software would require purchase, configuration, and management by our team.



Questions to the gurus out there:

Is there anyone out there using Microsoft TFS and can shed some light on what we could expect if we moved to it? Are there particular settings we need to change on the server or client side to enable better compatibility?

Is there anyone out there using Vault (www.sourcegear.com) and can share their experience with using it with Dev Studio?

Is Subversion a worthy alternative compared to trying to convince the team to purchase PVCS or Vault or other software?

This message has been edited. Last edited by: Kerry,

We have been using Subversion with WebFOCUS.
The "integration" with Developer Studio is not worth bothering with, it doesn't work very well. But you don't really need integration, you can control your sources from explorer just fine. Better integration would be appreciated though, IBI could do something about that.

I have never worked with Microsoft's source control systems, but I've heard nothing but horror stories. There are several good open source alternatives, like aforementioned Subversion, Mercurial and GIT, all with their respective cons and pros.

They're all reliable, fairly easy to set up and use and well documented. That's not surprising, as the entire open source community (ranging from application developers to operating system teams) use it on a day-to-day basis. Many commercial companies use them too, obviously. Bugs, if you manage to encounter one, are fixed well and quickly.


In the end we chose to use Mercurial (aka Hg), primarily because we also needed source control for a couple of VMS systems here. Subversion didn't appear to support that OS very well, while Hg does. Another difference between the two is that Subversion works with a central repository, while Mercurial works with local repositories.

Which is best depends on your needs, but we find it convenient that Mercurial allows our developers to commit when they feel the need, without hampering other developers with their unfinished (but committed) code. When a piece is finished, it gets merged into a "central" repository from which everyone synchronizes their sources regularly.

We found that with Subversion, developers tended to hold off commits until they were finished with a change-set so as not to hinder each other, which was bothersome if one ran into problems with the uncommitted change-set he was working on. Most editors have finite undo-buffers, for example, so it has happened that someone had to rollback their entire change-set and start over from scratch. Having the ability to commit in between would definitely have saved trouble there.


Finally, there's one type of source-code we've not managed to put in source-control in a convenient way: remote focus executables for, for example SQL code. Those can't be run on the local (developer) machine, as that's not where the DB is, which means you can only test them on the remote machine. I've tried keeping a local copy of such files, but they tend to get out of sync with the real ones at the remote server, as that's where bugs get fixed in such files.

We use Sourcegear Vault integrated with custom code to handle source control for the .NET code of our ERP and, of course, we'd like to use that for WF, too. We have a lot invested to move to another source control platform and ahve our integrated solution dialed in to pass our SSAE audit.

Consequently, we have an NFR to get Sourcegear Vault integration for WF: IBI CASE#80592536

Something I was made aware of on the recent Benelux Summit is that starting with WebFOCUS 8, procedures are no longer stored directly on a file-system! They are stored in a database instead. I did raise the point of how we could apply source control in that scenario, I have yet to receive an answer.

quote:

The only other source control servers available to us in our organization are TFS 2008 and Vault. Any other software would require purchase, configuration, and management by our team.

Obviously, Open Source source control products do not require purchasing. The configuration and management arguments don't really apply in many cases either, as most of the repository management is usually stored inside the repository - under version control as well.
If you go with a source control system that requires a central repository, then you obviously need to set up and manage that central repository.

There are also a number of distributed VCS's these days though, most notably GIT and Mercurial, for which you don't need a central repository (although assigning one to be just that is probably smart).
A distributed VCS seems a weird concept initially, but it definitely has its merits (I was sceptic initially).
One of the more important benefits is that, since every developer has their own repository, they can commit (to their own repo) whenever they want without any risk of disturbing the work of others. That means that as a developer, you can take alternative approaches and revert back to where you were if it doesn't work out how you expected, for example. Once you're confident it's ready, you push it to a "central" repo.

A distributed VCS is probably only really useful if every developer runs their own WebFOCUS development environment, but with the amount of devs the OP is talking about I don't think it'd be viable if they'd all work on the same files concurrently. The drawback there is that focus-files won't be shared among devs automatically - we have several focus-files that are just under 1GB in size, some of which take several hours to generate on beefy server hardware, longer on desktops if they complete at all.

None of those integrate with Dev Studio, but then, only few VCS's do.

We use TFS and have been able to integrate it with DevStudio without much ado, but that doesn't mean IBI provides much functionality in regards to source control.

DevStudio's support for source control systems is...suboptimal (regardless of vendor).
Using projects (in DevStudio) doesn't work well as branching isn't supported. This is quite debilitating to the use of source control. There is a way to mitigate this in TFS by using "workspaces" but it requires developers to remember which workspace they're checking code out to above and beyond which branch they are working in. We plan to take another stab at figuring the best methodology to use but for now we disabled the SCC integration in DevStudio and are managing it directly in TFS.
Given we are focused on MR development in WF8 we're also trying to determine how to manage source control, versioning, diffs, etc. given the objects are stored in the database.

I would like to see some file based representation of the fex/etc. on the DevStudio machine for use with source control...let alone simple file diffing software. Realistically they should revamp the "Project" concept in DevStudio to work with MR as well and support SCC branching as well as publishing from a "Project" to MR, etc.

I'll update this thread when we tackle this thorn again.

Kevin

As an aside, I have used Visual SourceSafe (VSS), svn, SourceGear Vault, Team Foundation Server (TFS) and AccuRev and others I've forgotten about.

TFS is rock solid and I recommend it, if you already have licenses for it. It is fully enterprise ready and the integration with Visual Studio is great. I was reticent to use it given poor experiences with VSS but it truly is a different product and we've had no issues with it other than maybe a few wish list items on change history across branches, etc. I do like SourceGear Vault and selected that as the SCC vendor of choice at a former company. AccuRev is our corporate standard and I really liked using that tool, but it's been about 6 years since I last used it (I imagine it's even better now). In my current division we are split between svn and TFS. I like TFS better than svn, but then again, you have to pay for TFS. I would not use VSS as it is highly unstable and we lost code at a former company as well. Our division hasn't moved to AccuRev due to licensing costs, downtime in converting over and current investment in svn and TFS.

Probably more than you wanted but I started typing and couldn't stop :-P

Hi,

Is there any integration/plugin to App Studio 8.1.05 to use AccuRev?

I´d like to use it to control my codes/fex.

Thanks

Version 8 does have file storage like 7, but also a DB repository where you can store files. We use PuskOK with subversion which integrates in Dev studio for the DB repository. It works but not great, file keep their locks sometimes and in genral it's slow.

I've understood that in 8.2 there will be an integrated source control in WebFOCUS app studio. Hopefully they will be using git.