Which source control system (I know, too general)

[Gary Niemen]

My question is, in a way, simple - we need and want to implement source control for our large Flare project, but which source control system shall we go for? Yes, I know, I am not supposed to ask such general questions, but I think in this case it makes sense to do so. Our goal is simple. A source control that works with all the features one would expect from a source control system. Here is some background that will, I think, enable somebody (or somebodies) to answer my too-general question.
ClearCase: Our company is using ClearCase at the moment. We tried to implement source control using ClearCase, but discovered that merging was problematic and history was lost when moving files from one folder to another (in Flare). Two show stoppers. But, anyway, we won't be using ClearCase because...
Acurev: Our company is moving in the new year to Accurev. It seems to me that we will have the same issues as we had with ClearCase (merge problematic, history lost when moving files) because we will need to use the same general API. The advantage is that the IT department will support us, but I am not convinced it is worth pursuing or testing because I don't think it will work.
GIT: Some teams will be allowed to use GIT next year. Not convinced for the same reasons outlined above.
Subversion: Shall we just go for this, a MadCap-supported source control system. Does it work? Does merging work? Does moving files from one location to another work? Does it help to solve Flare's performance problems (when working over a network). Does everything else work? We are willing to set it up and test, but before we do, I would really like some reassurance (from those who have walked before). Does it work? We will have to support ourselves. The IT department will help a little, but basically we are on our own. Is it doable without too much support from the IT department.

Interesting insight: It seems to me from reading other posts that, basically, Flare supports the exact source control systems that tend not to be implemented in large software development environments (Perforce, Accurev, ClearCase, GIT).

Anyway, so the question becomes: Should we go the Subversion route. We will be on our own, implementing a source control system that nobody else in the company is using? If it works then, for me, it is worth it. But if it doesn't work, or if it is too difficult and time-consuming to manage, or it doesn't solve the network performance issues that we have with Flare - then it is not worth it. But, then, what to do? Because it looks like Accurev and GIT will not work either.

Any help appreciated.

[RamonS]

It is the same question as "Which authoring tool should I use?" Depending on who you ask you get a different answer, some say Flare, others are hellbent on defending their choice of Frame with WebWorks others claim they can do everything in Excel (not kidding here).
I suggest you give Accurev a try anyway. It is the system that developers will use and for the sake of build automation you want to have help sources be in the same source control system. If your suspicion turns out to be true I suggest to try Git. It is currently the most modern open source source control system.
The question is if anyone of the above can be used directly from Flare. Accurev claims to interface seamlessly with VisualStudio which makes me think that it supports the Microsoft SCC API. As for Git, PushOK has a plugin that will make Git compatible with the MSSCC API (see http://www.pushok.com/software/git.html). Others had good success with the PushOK plugins. Git was designed to support merging as in the projects it was created for a merge is the most common form of submission.
Subversion will work and I have used it with Flare. I am not convinced that Subversion will do any better than the others when it comes to merging, but it would be a system exclusively for tech docs and you can set the rules of engagement, a luxury you won't have with the systems the developers use.
I worked with VSS, TFS, CVS, and SVN and they all have some major flaws and annoyances. They all are incredibly slow and tend to be needlessly complicated although SVN with Tortoise is about as easy as it gets, but there is a reason why the front end was called after an animal that is known not to excel in speedy travel (which isn't true by the way, some turtles can run quite fast). I haven't had a chance to use Git, but the intention behind Git is also to make it perform reasonably well.

My suggestion is that you look at all three (Accurev, Git, SVN) and pick the one that works best for you and for the projects in general. I don't see any purpose in looking at ClearCase again because you already did that, found it to be unusable, and your company is dumping it anyway.
One more option is to use the free hosted TFS service from Microsoft assuming that it can be hooked up to Flare without problems, see here: http://tfs.visualstudio.com/

[Gary Niemen]

That's a very good answer. Thanks.
You say that Subversion has some major flaws and annoyances. What are these? Or is it just the performance?
This would be a problem I would say, as one of the reasons we are trying to get Flare into source control is Flare's poor performance when working over a network (in a distributed environment).
Also, any other input?

[RamonS]

Yes, it is mainly performance, but when I look at TFS then horrible performance is not just a Subversion issue. More an annoyance is the difficulty in operating Subversion. In this day and age any reputable app should come with a native GUI frontend and not depend on additions such as Tortoise to cover only a subsection of the functionality. Also, using Subversion via HTTP is incredibly slow, the propietary SVN protocol performs much better, but is also more difficult to configure.
What I want from a source control system is this when starting from scratch using a GUI:
1. Install source control system
2. Create user accounts
3. Create repositories where I want them with the folder structure that I want
4. Assign users to repositories
5. Start checking in / out and merging at about the same speed as a web or file system transfer usually takes (yes, the system needs to manage the submissions, but how long can that take?)
6. Make it easy to move the entire system to a different server (install on new server, tell old source control on old server where new server is, then move stuff 1:1)

Source control is supposed to be a tool that supports the actual work, not a complicated app that requires as much attention and effort as the actual work.
As far as SVN is concerned, I think some posts further down I described steps on how to get SVN working with Flare without much of the hassle. While the outcome is a working setup it sorely lacks #5.

[Msquared]

If I could choose the source control system to use, I would strongly recommend that you go with one of the couple of options that MadCap claims to support directly, not anything that relies on the Miscrosoft SCCI API, and definitely not Perforce. It doesn't work.

From my experience, if you have problems, you will be unlikely to get a resolution unless you use one of the directly supported options.

Our developers use Perforce, so I have to use that. I'm an ex-developer so I understand source control but I have had all sorts of problems with Perforce and Flare, and reported many bugs. Madcap don't have a Perforce installation, so can't reproduce any of them. Although their tech support are always helpful, I do wonder how likely they will be to fix any of these bugs that they can't reproduce.

To be fair, our developers say they have trouble integrating Visual Studio with Perforce too, but even if the problem is the Perforce end, until MadCap investigates from their end I've got nothing to go to Perforce with.

The bugs are major, like, for example, you can't build the source control cache, Flare hangs. You can't select the option to get the latest version of the source control, Flare hangs. You can't move files from within Flare if the project is connected to Perforce, Flare hangs. You can't rename files from within your project, Flare hangs. You can't delete files from your project, and select the option to delete them from source control. Flare hangs (at least that one you can control without having to remember to stop, close the project and re-open it without the Perforce connection before proceeding). The View > File List doesn't work if the project is connected to source control, Flare hangs. I expect you get the idea. In every single case, once Flare has hung, you have to delete lots of cached files from your project, or the crashed project won't open at all.

Today I have reported another possibly related bug. I can't create a review package in Flare. Flare doesn't actually hang, it just reports an error, but once I've tried and failed, I can't open the project at all with the source control connection, even after deleting the usual slew of suspect cached files. Flare hangs.

Having got that off my chest (today has been a very frustrating day), there is another Source control possibility I would love to consider. Flare claims to support Sharepoint, which I love, but my present company isn't keen on. We had no source control for documentation in my last place, so I implemented a system using Sharepoint, which we did have, and it worked really well. There were a few small glitches, but once you learned what they were, they were easy to work around.

Flare claims to integrate with Sharepoint, so if I were (a) able to use a different source control system from the developers and (b) resurrect Sharepoint, which my current company has recently phased out in favour of Confluence, I wouldn't be writing this now, in a state of Flare/Perforce induced frustration. I'd be trying to set something up in Sharepoint.

[RamonS]

To my point in an earlier post, if you ask 2 people you get 3 answers. We use SharePoint (which really is just TFS with a craptastic web front end) for document source control (non Flare) and I loathe it with every fiber of my being. In my opinion SP is the worst option. Copying backups to a network share is less hassle and by jolly much faster for the most part gets you the same limited capabilities that SP has. SP is clunky, complicated, riddled with bugs, and excruciatingly slow. On top of that, it only works somewhat in IE and I have my doubts that it does merging any better than other systems (my money is on it doing a worse job unless all you deal with are Word docs).
As described by Msquared your mileage may vary. The basic version of SP is available as download from MS and once you overcome the ridiculously complicated installation / implementation you can give that a try.

[Gary Niemen]

Thanks all for your input. Extremely useful to get input from this general level (it is what I had hoped for when I posted my "too-general" question). If anybody else wants to rant/rave/praise, I am interested.

[techwriter31]

We're using ClearCase integrated with Flare. We don't perform any automated merges and use reserved checkouts so that only one person can edit a file at a time. Overall, it's worked pretty well for us.

Here are the problems I've found (all reported to MadCap as bugs). But as Msquared pointed out, ClearCase isn't directly supported with Flare (we use the Microsoft SCC API), and thus these bugs most likely won't be fixed.

Problem: Cannot rename view-private files in Flare. If you attempt to rename the view-private file within Flare, it automatically updates the links to correspond with the new file name, but does not actually rename the file.
Workaround: Add the file to source control, and then rename it. If you have already attempted to rename the file in Flare and it failed, you then need to rename the file from Windows Explorer. Since Flare already updated the links to this file, once renamed in Windows Explorer, it should function properly.

Problem: Condition tags are often removed at the file level when adding files to source control.
Workaround: Add files to source control prior to applying condition tags at the file level.

Problem: Flare gets out of sync with ClearCase for the checked in / checked out state of files. For example, the Pending Check-Ins pane might not show any files in the list, but if you perform a "Find Checkouts" or update your view in ClearCase Explorer or Windows Explorer, ClearCase finds files in the project that are still checked out.
Workaround: Click the Refresh button in the Pending Check-Ins pane. Also, periodically update the view using ClearCase Explorer or Windows Explorer, to ensure your files are synced.

Problem: If you attempt to add a new folder to a project that is bound to ClearCase source control, you get a ClearCase error stating that there was an error checking in the file and that the element name was not found.
Workaround: Using Windows Explorer, navigate to the location where you would like to add the folder. Add the folder with the appropriate name. In Flare, add the folder to source control.

[Gary Niemen]

Interesting to read about ClearCase, thanks.
The entire thread really helped me get some clarity around this issue - and we have decided to push ahead using Subversion. I have it set up now, so I will try various use cases and see how it goes.
We will also, later, experiment with Accurev (our software development source control system).

[Msquared]

I'd certainly be interested in knowing how you get on with Subversion. I am close to the end of my tether with Perforce, but I don't have the time, inclination or enthusiasm to try anything else unless I know someone has been there before me, and that it's going to do what I need it to do.

I think Perforce would be OK (at least no better and no worse than anything else), if only I could get the bugs in the Flare/Perforce interface fixed. And there's the rub.

[i-tietz]

Ok - one system more: MS Visual Sorce Safe (VSS).
We use the version 2005 and have no performance problems whatsoever. But Flare has its problems with it, although it's a SC tool Flare officially supports ... e.g.:
I check in everything of a project and delete my local copy of it. Some time later I get a current version out of the database. When I work on topics and want to check them in again, Flare tells me, that there is a newer version of that file in the database and Flare offers to merge it ... BUT:
1. The version in the database is NOT newer - my local version is. In the database itself, the file also shows an older date. So what causes that false message?
2. What I see in the merge tool is strange, to say the least:
a. Flare marks paragraphs as "changed" which I didn't touch and in the merge tool they are identical.
b. Sometimes I get to see a completely different topic in the area for the merge result in the merge tool. Sometimes that topic isn't even in the same folder - no idea where Flare takes that from.
3. The Pending Check-Ins very often show a strange combination
Status: "Checked out"
User: "gb" (that's the VSS account of a colleague)
But that colleague hasn't touched that topic for ages (sometimes years). And: If a User is given the Status should be "Checked out by other user".
4. Building a new SC cache after importing the project (Flare asks me to do that) is a bad idea - it makes things worse.

But we stick to MS VSS 2005 because
1. it has that gorgious feature called "linking": We can have files in the database that are there only once, but we link them into multiple projects. And when such a file has been changed every linked project knows that there is a new version to retrieve.
2. the administration GUI is excellent if compared to Subversion - don't know any other SC software.

[trent the thief]

Ok - one system more: MS Visual Sorce Safe (VSS).
We use the version 2005 and have no performance problems whatsoever. But Flare has its problems with it, although it's a SC tool Flare officially supports ... e.g.:
I check in everything of a project and delete my local copy of it. Some time later I get a current version out of the database. When I work on topics and want to check them in again, Flare tells me, that there is a newer version of that file in the database and Flare offers to merge it ... BUT:
1. The version in the database is NOT newer - my local version is. In the database itself, the file also shows an older date. So what causes that false message?
2. What I see in the merge tool is strange, to say the least:
a. Flare marks paragraphs as "changed" which I didn't touch and in the merge tool they are identical.
b. Sometimes I get to see a completely different topic in the area for the merge result in the merge tool. Sometimes that topic isn't even in the same folder - no idea where Flare takes that from.
3. The Pending Check-Ins very often show a strange combination
Status: "Checked out"
User: "gb" (that's the VSS account of a colleague)
But that colleague hasn't touched that topic for ages (sometimes years). And: If a User is given the Status should be "Checked out by other user".
4. Building a new SC cache after importing the project (Flare asks me to do that) is a bad idea - it makes things worse.

But we stick to MS VSS 2005 because
1. it has that gorgious feature called "linking": We can have files in the database that are there only once, but we link them into multiple projects. And when such a file has been changed every linked project knows that there is a new version to retrieve.
2. the administration GUI is excellent if compared to Subversion - don't know any other SC software.

Given a choice between VSS and a sharp stick in the eye, well, give me my stick now.

VSS doesn't have the horsepower to handle help projects with multiple writers. I've been down that path. It was a horrible experience. We overloaded the VSS server the first time three writers simultaneously saved large projects. The developers screamed bloody murder. VSS works fine with source code, but dump several hundred images, PDFs, spreadsheets, and a few thousand html files into it and it chokes. VSS isn't built for high volume situation that can include binaries.

AccuRev handled the volume of files, but was very awkward to use within Flare.

The company I work for uses Subversion. We're really pleased with it. Also, IMHO, I'd rather have the explorer integration provided with Tortoise. It does the job just fine. SVN works just fine without supporting the bulk a GUI would add to it.

The only hitch that might show up with SVN is in how you access the server. If you bind the project to a repository using "svn+ssh://releng@scm.yourdomain.com/" you'll have an issue with SVN within Flare because your SSH credentials somehow get tangled into the system and other writers won't be able to access the files. However, if you use a WAN/VPN/Intranet and can "see" the server without SSH, then you're golden. We just changed over to a full VPN network and we're pleased as punch with how it works now. We'd been managing SVN manually from Explorer.

[i-tietz]

VSS doesn't have the horsepower to handle help projects with multiple writers. I've been down that path. It was a horrible experience. We overloaded the VSS server the first time three writers simultaneously saved large projects. The developers screamed bloody murder.

We are using it for 4,5 years now - we've been a max of 6 writers working on it simultaneously and we never had problems.

VSS works fine with source code, but dump several hundred images, PDFs, spreadsheets, and a few thousand html files into it and it chokes. VSS isn't built for high volume situation that can include binaries.

Could be, because we do have several projects with several thousand topics and some 3-digit number of pictures, but we're not producing for print, means: pictures have a max 57 kb file size.
=>
The whole VSS folder (on a network drive) has a size of fourhundredandsomething MB.

And we never had serious problems so far. But we undergo a monthly maintenance session of the db (using built-in VSS tool) with the odd broken file being replaced.

[i-tietz]

The only hitch that might show up with SVN is in how you access the server. If you bind the project to a repository using "svn+ssh://releng@scm.yourdomain.com/" you'll have an issue with SVN within Flare because your SSH credentials somehow get tangled into the system and other writers won't be able to access the files. However, if you use a WAN/VPN/Intranet and can "see" the server without SSH, then you're golden. We just changed over to a full VPN network and we're pleased as punch with how it works now. We'd been managing SVN manually from Explorer.

looks like a command-line-driven tool ... takes me back to those days when we used MS DOS, and Windows was a blink in the eye of Billy-Boy Gates.
Hands up everyone who knows what Trent's writing about!

No, seriously:
We got an introduction lesson into subversion and tortoise svn last year - took half a day. And the mere thought of the havoc all but one of my colleagues would wreak in our database makes me shudder ...
A tool without an intuitive GUI doesn't make it into our tool park ... don't forget: Most writers are neither technicians nor developers.

[trent the thief]

The only hitch that might show up with SVN is in how you access the server. If you bind the project to a repository using "svn+ssh://releng@scm.yourdomain.com/" you'll have an issue with SVN within Flare because your SSH credentials somehow get tangled into the system and other writers won't be able to access the files. However, if you use a WAN/VPN/Intranet and can "see" the server without SSH, then you're golden. We just changed over to a full VPN network and we're pleased as punch with how it works now. We'd been managing SVN manually from Explorer.

looks like a command-line-driven tool ... takes me back to those days when we used MS DOS, and Windows was a blink in the eye of Billy-Boy Gates.
Hands up everyone who knows what Trent's writing about!

No, seriously:
We got an introduction lesson into subversion and tortoise svn last year - took half a day. And the mere thought of the havoc all but one of my colleagues would wreak in our database makes me shudder ...
A tool without an intuitive GUI doesn't make it into our tool park ... don't forget: Most writers are neither technicians nor developers.

The TortoiseSVN interface hides the command-line stuff. The "svn+ssh..." is part of the configuration that you'll only need to add once. It's the method of access the SVN repository.

[i-tietz]

The only hitch that might show up with SVN is in how you access the server. If you bind the project to a repository using "svn+ssh://releng@scm.yourdomain.com/" you'll have an issue with SVN within Flare because your SSH credentials somehow get tangled into the system and other writers won't be able to access the files. However, if you use a WAN/VPN/Intranet and can "see" the server without SSH, then you're golden. We just changed over to a full VPN network and we're pleased as punch with how it works now. We'd been managing SVN manually from Explorer.

The TortoiseSVN interface hides the command-line stuff. The "svn+ssh..." is part of the configuration that you'll only need to add once. It's the method of access the SVN repository.

aha ... thanx for enlightenment.
And what is the "repository" and what is it that you call "SSH credentials" ... and what about WAN Intranet? VPN Intranet? ... how do I "see" the server at all, let alone without SSH - and what is SSH anyway? ... and a VPN network? ...

As you see: A lot of "???" for non-technicians. It's as I said: Most writers are no sys admins or developers ... I repeat the claim: A GUI has to be intuitive or it will be misused - either due to memory holes or to lack of acceptance and motivation.

[trent the thief]

The only hitch that might show up with SVN is in how you access the server. If you bind the project to a repository using "svn+ssh://releng@scm.yourdomain.com/" you'll have an issue with SVN within Flare because your SSH credentials somehow get tangled into the system and other writers won't be able to access the files. However, if you use a WAN/VPN/Intranet and can "see" the server without SSH, then you're golden. We just changed over to a full VPN network and we're pleased as punch with how it works now. We'd been managing SVN manually from Explorer.

The TortoiseSVN interface hides the command-line stuff. The "svn+ssh..." is part of the configuration that you'll only need to add once. It's the method of access the SVN repository.

aha ... thanx for enlightenment.
And what is the "repository" and what is it that you call "SSH credentials" ... and what about WAN Intranet? VPN Intranet? ... how do I "see" the server at all, let alone without SSH - and what is SSH anyway? ... and a VPN network? ...

As you see: A lot of "???" for non-technicians. It's as I said: Most writers are no sys admins or developers ... I repeat the claim: A GUI has to be intuitive or it will be misused - either due to memory holes or to lack of acceptance and motivation.

Every server has some method to access it. You credentials are presented to the server and you're given files or permitted to modify files. There's an access string that the server must see before it grants access. the "SVN+SSH" tells the server that access is via ssh.

When the method is SVN+SSH, the server somehow associates the access credentials with the files, thereby blocking any other users from accessing them.

A GUI you can modify is handy. That's why so many people use Tortoise. There are other front ends for SVN, CVS, etc. The developers who maintain the SVN project have a single goal, and that's to make sure that their server is rock solid. They leave OS integration in the form of a GUI to others. The reasoning is that source control is a tool that's primarily for developers. Developers don't want deal with a GUI. They want integration with their primary editor or IDE.

SC servers that try to provide a GUI and a server generally achieve mediocrity at best.

What sort of systems do you document? I sometimes forget that everyone doesn't write computer/programming docs

[i-tietz]

A GUI you can modify is handy. That's why so many people use Tortoise. There are other front ends for SVN, CVS, etc. The developers who maintain the SVN project have a single goal, and that's to make sure that their server is rock solid. They leave OS integration in the form of a GUI to others. The reasoning is that source control is a tool that's primarily for developers. Developers don't want deal with a GUI. They want integration with their primary editor or IDE.

Maybe if they HAD an intuitive GUI they would be able to access new target groups ... i.e. students working on theses, authors working on books, web designers working on websites, ... but they're (open source) developers ... best example I can think of to show how strange (open source) developer minds work: The link "Random Article" at wikipedia / in wikis ... who on earth wants to read "random articles"? - Apart from obviously developers, that is ... maybe their usual lack of structure simply establishes itself in their whole life ... and why isn't there a link for adding a new article? That would make tons more sense ... ...

Ok, I stop my ranting at (open source) developers. - Let's just say, that they will never kick MS or Adobe or Apple out of business.

[RamonS]

Open source developers are mainly making better software for themselves. If that means they can help out others at the same time, even better. Most open source projects are purely voluntary work, only a few get endorsements by companies, such as Microsoft (they learned). Apple's OS X is entirely based on BSD which is open source. The world's most popular mobile OS is Android which is open source as well. Android has over 60% market share in the mobile industry kicking the Apples and Microsofts where it hurts. Especially Microsoft has no game in the mobile market despite having a former great (Nokia) as puppet for hardware and trying on their own as well with ridiculously overpriced tablets (Surface). Apache is still used on two thirds of all web servers in the world and this very forum is coded with PHP, in both cases open source projects. Apache has a well documented and easy to understand configuration file. In comparison, I still can't figure out the needlessly complicated GUI of IIS. Further, an entire industry built around PHP which as programming language is always solidly in the upper ranks of the TIOBE index.
As far as CSV or SVN are concerned, these are systems that are not predominantly used through a stand-alone UI. And if there is a need Tortoise and several other GUI frontends are available. In the developer world especially CVS and to a lesser extent SVN are passé. The better solution is Git and for that there is TortoiseGit, also an open source project.
Open source even expands beyond desktop software. There are open source cloud stacks and open source hardware. Most satellite receivers and cable boxes run open source platforms, most consumer network routers and wireless access points run on open source. In fact, I am looking at one of the newest open source hardware platforms right now: Raspberry Pi. At 35$ it is a complete computing platform running Linux, it is capable of playing HD video (there are ports of open source media centers available), can run the LAMP stack (yes, MySQL is an enterprise grade open source database system and there is an excellent GUI for that). The Pi also has USB and network right on the board as well as a good amount of programmable I/O. That I/O can be used to talk to yet another low cost open source hardware platform: the Arduino.

Most of these open source projects are not created with the sole purpose of making a lot of cash, but there are still plenty of companies that make a lot of money off open source. There are proprietary, closed source solutions that in some cases work much better, but often enough all they have going for them is a pretty GUI. Open source is all around us and while it may not take Microsoft out of business it clearly makes it so much more difficult for Microsoft to enter new markets. You can get a decent Android tablet for half the price of the Surface. Both will run none of your Windows desktop apps, even worse if you want to use MS Office on the Surface you have to buy an extra desktop license! And if the Metro ....errr.... Modern UI of Win8/Win8RT/WinPhone8 is so much better than the rest is debatable. Open source did a lot for the computing industry and it feeds a number of people (among them the poster boy Linus Torvalds who gets a 10 million Dollars annual salary).
Lastly, I like the Wikipedia random articles and articles of the day. It is my main source of expanding my general knowledge even when it is about topics I am not that interested in. MediaWiki is also open source and yes, it has a rather quirky markup language, but using HTML would not have been any better. With a handful of markups you can create wiki articles. And if you want to contribute to WikiPedia have a look at the help file here: http://en.wikipedia.org/wiki/Help:Getting_started
So, now why again is open source just a dysfunctional mess?

[i-tietz]

Wiki and Linux are both about 20 years old. And where are they?
What open source developers do is mainly playing around with their favoured toys. It mostly lacks professionalism utterly for the very simple reason that they don't have to accept liability for their opus and whatever goes wrong if you use it. E.g. one of my former employers went bankrupt because they worked with open source software:
A special open source database for processing and storing pictures was buggy. Our developers used it to generate a greeting card module for our biggest customer. He used that module for a special offer for his customers (4-digit number of recipients). When about the 100th of his customers wanted to see the card, his webserver was put to a complete halt - no memory left - because of that bug in the database. Yes: "Our" developers were open source developers too and simply trusted the other ones. Serious testing seems to be an almost insulting behaviour.
Result: That customer of ours withdrew all current orders and further plans ... and rightly so! I fully agree with him - that was a rubbish job. Consequently 10 out of 12 colleagues lost their job - including me.

That's my experience with open source software and open source developers. Open Office is the only positive example in a long row of junk.

And there are plenty of tech writers with no software or hardware background knowledge, because e.g. they approached the job from the side of language or journalism. They are far better off with a software that has an intuitive GUI - and Tortoise or Subversion do not really belong to that subset of software.

[RamonS]

The example you gave can happen with proprietary software as well. I used to work for a division of an international company. The mother company itself is still operating because it diversified, but the division with both software and hardware no longer exists. The software branch was the first to go mainly due to bad technological decisions. The lead developers insisted on using Access as database with VB6 for the program code and DCOM for multi-client capabilities. Access sucks as a database for anything other than casual use, Microsoft pulled the plug on VB6 so technologically it was a dead end, and after MSBlast/LoveSan put DCOM on IT's sh**list and the modifications that Microsoft made to DCOM later resulted into a 27 page instruction manual. The design of the app also required network shares to be created for every client, which wasn't great either.
We all know better now, but back then this was exactly what Microsoft stated in its design guide documents to use. It was the most craptastic tech advice from a company I ever came across. Later I worked on a different product that was between a rock and a hard place. It used a one popular 3rd party component (closed-source) that could only be used with a specific version of the compiler. The company that made the 3rd party component went belly up. Replacing the component meant spending months in developer effort plus a couple months more to make the code compile on the latest version of the compiler. The decision was made to EOL the product and spend the time on making something new.
The number of failed closed-source projects is massive. In the end it doesn't matter if it is closed-source or open-source, but it comes down to sound technological decisions. And with open-source you always has the option to grab the source and fix/modify it yourself even if the project is no longer officially maintained. The case you describe seemed to lack in proper data layer abstraction. If designed right the database could be replaced with some effort. These days many make use of database specific features and stored procedures that are not as easily transferable but it is possible. And large binary objects such as images can always be stored externally with the database holding a reference. The downside there is that database records and file store could get out of sync, but I'd take that problem any time over losing a key customer.
Yes, there is a lot of crapware, vaporware, shelfware, and other useless junk around. Using that in professional settings is likely not the best idea, but as the VB6 example shows there is no guarantee that a major and generally reputable vendor does not pull the plug on platforms. The same can happen with .NET or Java and any one of the popular frameworks that developers use. Just imagine if Microsoft does the same to .NET that it did to VB6! One might think that would not happen, but it happened again with Silverlight. Unable to properly replace Flash it was a road to nowhere (and Flash itself is somewhat as well - also a closed-source platform). Microsoft now banks on HTML5/CSS3 which is already shown to be insufficient for RIA development.
MediaWiki is barely 10 years old and runs one of the most popular web sites (WikiPedia). The idea of a link based document markup system goes back to the 60s, yes, it is not new technology, but one that works well and is still in widespread use. Linux is at the base of Android phones and tablets and many other consumer electronics as well as making its way into enterprise systems. It was never meant to displace Windows and if you read what the Linux developers state as their goals then killing Windows is not one of them. Instead Linux is designed to be customizable and extensible to the nth degree. Show me any other modern general purpose OS that runs on 35$ hardware. There are none!

As fas a technical writers not having a clue about software and hardware, I call those people formatters. They may be well-versed in language and can make stuff look pretty. If they have no understanding of the technology they are writing about, how much tech are they? I agree, there are many of them around and many of them do a nice job given their skill set. An technical journalists are not tech writers. Those are the folks like the Grallas from ComputerWorld who demonstrate in every article how hopelessly clueless they are.

To bring this back a bit on topic, if a tech writers want to use source control then they need to understand what source control does, how it works, and how to operate the system they chose. Typically (as trent pointed out already), the source control services are consumed through the IDE (in our case Flare). The fact there the same people who code the source control system also do not code a stand-alone UI is rather irrelevant. Flare is the frontend and it does a fair job when it comes to SVN. The difference is that the source control system is a service running on a server, everything else is a client app consuming the services. In the same way you can use a Chrome browser to access services provided by IIS, or IE to access and Apache web server. As far as source control with Flare goes, there are a bunch of options and it is a case by case decision as to what makes sense to use. With a zero budget and some reliable hardware available using Subversion is THE way to go. If developers already use TFS and TFS build services and all this nice stuff (and in this case I mean it, TFS build services are quite awesome!) then hooking Flare into TFS is the way to go. Even with TFS in the mix the native GUI frontend is not used from Flare. Team Explorer 2010 is OK, version 2012 is horrible, and Team Portal on SharePoint is an app that should never have been written. Yes, TeamPortal looks pretty and is at times easy to use, but it is horribly slow and riddled with bugs.

[i-tietz]

Love - we know how much you love MS. - That's not the point.
The point is that MS is liable for what its software does or does not do. You don't stand a chance with open source.
And that freedom is abused by open source developers: They publish everything they consider ready - usually without thorough testing, and they don't give a damn on what the user needs but on what they find exciting. Instead of making existing features easier to use they prefer to turn to the next toy.
You don't spend a lot of money - true, but you get what you pay.

[trent the thief]

Love - we know how much you love MS. - That's not the point.
The point is that MS is liable for what its software does or does not do. You don't stand a chance with open source.
And that freedom is abused by open source developers: They publish everything they consider ready - usually without thorough testing, and they don't give a damn on what the user needs but on what they find exciting. Instead of making existing features easier to use they prefer to turn to the next toy.
You don't spend a lot of money - true, but you get what you pay.

If you didn't have such a high post count, I'd figure you for a troll.

There aren't very many open source database projects lying around. At least not those that a business would really consider to be capable of handling business critical operations. I can't speak to your previous company's choice of DB since you didn't share it with us. But I am curious if you can provide any insight into why, if they were committed to open source, they didn't choose MySQL?

As for being responsible for products, you can hardly hold MS up as a paragon of virtue. Their track record is there for all the world to see and it's pretty dismal. Especially when compared to open source producers of enterprise-level software. Apache httpd, Apache TomCat, JBoss, Python, PERL, JIRA, all are open source producers that respond quickly to security problems and actually speak with users to correct deficiencies. Especially those issues related to security.

Microsoft's record speaks for itself. They have a too big to fail attitude and that's why they can't manage to gain very much headway in the smartphone market and are even losing marketshare in the embedded OS arena. Android is kicking them to the curb.

But anyway, you're entitled to go with whatever lets you sleep at night. If you're impressed with a flashy GUI, you do truly get what you pay for. Even if that is mainly a flashy GUI. I'll keep on using a solid server with the front end of my choice that exactly fits my needs. And you have to ask yourself, if VSS was so wonderful, why is it that MadCap's building SubVersion compatibility into Flare?

[RamonS]

Love - we know how much you love MS. - That's not the point.

Yes, I am very critical of Microsoft products, but I am very critical of every software product. The main reason is that I work as a software QA professional for over 10 years and got to understand how good software is supposed to be. And yea, there is also a good portion of subjectivity.
That said, I always considered Microsoft's development tools to be the best in the industry. That is why many other IDE vendors copy the VisualStudio design and developers are used to having the workspace in the middle, the menu strip at the top, status window at the bottom, and property windows and browsers on the side(s). That said, I have no idea which moron designed the UI for VS2012, but there are workarounds. I find TFS build services incredible and I also was impressed how easy it is to create web apps using MVC4 and C#.

The point is that MS is liable for what its software does or does not do. You don't stand a chance with open source.
And that freedom is abused by open source developers: They publish everything they consider ready - usually without thorough testing, and they don't give a damn on what the user needs but on what they find exciting. Instead of making existing features easier to use they prefer to turn to the next toy.
You don't spend a lot of money - true, but you get what you pay.

So when your systems get compromised because of a Windows zero-day vulnerability Microsoft is liable for the damage? Read the EULA that you signed and you will know that it is not true. Microsoft doesn't even agree to patching anything and as we all know from the CHM viewer they might even just disable features rather than fix security flaws. Maybe you mean something else by "liable", but there is no liability connected with any software I know of. Efforts are under way to introduce mandatory software warranty beyond what the century old trade laws cover (in the US), but even then liability will not cover bad tech decisions. And there is no difference in that regard between proprietary/closed-source and open-source software. Keeping applications up to date and fixing bugs is a means of customer retention and therefor is common for any software company and open-source project. The exception is abandonware which is fairly easy to spot and not a matter of open-source of closed-source. Examples: I bought a license for SageTV which was actively developed and had a large customer base. SageTV got bought up by Google and Google canned what was/is undoubtedly one of the best PC multimedia suites. As for Microsoft I already mentioned VB6 and anything pre-DotNet. And for open-source projects take a look at the Sourceforge pages or project websites, if the app never made it past an alpha or beta release or the last post on the site is three years old then forget about it. Nobody stops one from using the apps, but don't expect anyone answering questions or patching or accepting any liability of any kind. As mentioned before, the type of software license and development model has nothing to do with bad technical decision making and the lack of bothering with business continuity. It is unfair to claim that your one bad experience is the norm for open-source, quite contrary. Do you honestly think that companies like Samsung would chose an open-source based mobile OS for its products if it resulted in sure doom? Your generalization is just not true.

The claim that open source developers release without testing is entirely baseless for the most part. Pick any one of the popular and less popular open source projects and you will find that there is some bugzilla instance or the like out there. Many open source projects have a very active volunteer testing team and in case of Apache the task of patching made it even into the product name. I submitted many bug reports to various open source projects and found that this helped getting bugs fixed. There is only one case where I found that developers turned from open eared to arrogant beyond repair and that is Mozilla with Firefox. Firefox was successful because it was different and went for what users wanted, now they just ape whatever dumb idea Google puts into Chrome. If folks want something that is just like Chrome then they will use Chrome and that is exactly what happens.

Paraphrasing Leonard Bernstein, there is no such thing as open-source or closed-source software, there is only good and bad software.

[i-tietz]

Tech writers are mainly specialists: Some are good in language, some are good at making concepts, some are good at computer tech, but most are good at whatever they describe, such as machines, airplanes, toasters, mobile phones (for Americans: cell phones), TV sets, power stations, ...
And I can recommend Subversion + Tortoise for those that are good at computers and not for all the others.