Having an engineering/development background, I’m familiar with these lovely things called version control systems. Unfortunately now that I’m a business analyst, on a team that’s tasked with maintaining a documentation set and currently have to manually (eyeballs and fingers) merge changes into documents. I’m thinking that surely, Surely, there is a team of people out there in the world also tasked with managing documentation and doing it with software. The developers in my company use HG Mercurial. If you’re familiar with that one, do you think we could use it for non-programming-code-documentation? Our docset is just Word and Excel files.
If your team uses something else for this purpose, what do you use?
I should add that what we’d need it for is to manage a primary doc-base (like a code-base) and manage branches, to be able to “diff” two versions of a document to see what’s different, to be able to merge two documents together intelligently, and if possible (read: nice to have) automatically merge a whole branch back up into the primary. Oh yeah, and a tool that will let us search all the docs (in a branch) for text strings.
Sharepoint is the Microsoft sanctioned answer to version controlling office documents but a quick survey of how much people love Sharepoint will give you a peek for how much pain you’re about to encounter.
TortoiseSVN has built in support for diffing word docs. If you want to store your docs in the same repository as your code, you can use TortoiseHg and hack it to diff using TortoiseSVN.
Ugh, we have Sharepoint. I could be wrong because it has many features we don’t use for various reasons, but it doesn’t seem to manage branches or have a “diff” utility or merging. It’s version control is barely passable, one step up from Windows file locking.
Or am I wrong about all that and need to talk to our Sharepoint manager about possibly buying some add-ons and such?
We used to use the MS software rev tool, whatever the original one was - SourceSafe? - to manage a rather large and complex documentation scheme. There are probably better ones now.
Or maybe not. Most seem to be written by programmers for programmers and don’t really acknowledge the way tech/doc writers work. Kind of like the add-on that let programmers write a block of doc in each function, and then extract/assemble them into a Finished Doc for the App! Yay! (sigh)
We use Perforce. It has all the features you’ll need including an MS Office plug-in. I really don’t know much about it outside of using it for source code control but it’s not oriented to any particular type of document, and it’s got good diff and sync tools, including the ability to revert.
I tried to look at the website for Documentum and the whole website is all BS marketing brochure with no detailed information. Quartz, can you give me a link for something like a feature list?
Perforce looked good, like it will work for us. I’ll dig a little deeper into that.
That is, unfortunately, par for expensive per-seat licenseware. You’re supposed to throw yourself at the feet of a sales ween, who after days of assessing your needs and wallet depth, will present a “proposal” for mumblety-thousand per user per year with maintenance fees and installation costs but WHAT AN IMPROVEMENT IT WILL MAKE IN YOUR PRODUCTIVITY!
Okay. Well I dug around the Perforce website and liked what I saw, so I think I’m going to try to justify us getting it. They have a free version for fewer than 20 users which will work for us, but I need to justify … well, the trouble of our IT folks configuring it on a server for us, explain why Sharepoint won’t work, and convince my coworkers to use it. It’s SO fun working in a corporate environment!
But Perforce has an additional feature that we can very much use and I was thinking I had to do manually: Swarm, which controls the review process. Since our documents are published to our global customer-base, they have to be worded correctly (dammit!.. according to the 5000 wordsmiths we have here…) so we have a serious review process set up. And it’s run pretty much seat of the pants right now. Formalizing that will make some of the touchy people feel better, I think.
I’m a SharePoint SME. What version of SP are you using?
The short answer, SP maintains major and minor versions (configurable option) of pretty much any permitted file type. If you’re using SP2013 or O365(in the cloud), you can do a compare between the current and any previous version for MS Word Docs, but not any other Office document.
There are third party solutions available but costs vary and your IT corporate policy will dictate what they will or will not add on to their SP environment. There is an Office/SP store that has some neat SP add-on solutions that are often free or nominal (petty cash expense). “Version History Pro” is one such tool ($9.99). You can find the add-ons here. There are hundreds of various useful SP solutions.
I’m not familiar with Swarm, but otherwise I find Perforce to be very useful and robust. Again, I work in a software engineering environment, I can’t say how it would work out for real humans, but one reason we use it is because It’s document independent. We are developing in numerous languages, OS, and hardware platforms, and we maintain documentation on it as well. All it needs to operate is to be able to store a file in a depot directory on your client machine. Perforce doesn’t care when, where or how that document was created. I assume at least some of those features will be useful to you as well.
I don’t know, is there a way for a “luser” to find that? Sorry for the snark. It’s just meant because we have a SP administrator who has it pretty locked down. We’re not allowed to do standard things like create our own workspaces or move files from folder to folder within a workspace that we’re allowed to create folders in.
This person and his manager are also protective with a fair amount of political clout, so they’re a blockade for any solution I propose that isn’t SP.
Between being forced to work/think/organize in a programming model, and having to go tug my forelock at the senior programmer tasked with accommodating us in their precious rev system, I developed a pretty fair antipathy for using a code-oriented tool to manage documentation revisions.
It sounds like there are better, doc-centric tools now, but as such things always are, they’re priced by the inhale/exhale.
I can help you identify which version you’re using. When you say “workspace” do you mean “document workspace”? If so, you’re probably usint MOSS 2007 or SP2010. In SP2013 MS did away with document workspaces.
Tell me this… when you want to find out details about a document in your document library/folder, is there an ellipsis (…) that you click on or do you just hover over the document and select options from a pull-down menu?
If the latter, then you are NOT using SP2013.
The link I sent you is an MS Office solutions store. I don’t know how many of them will be applicable to SP versions older than 2013
As to your SP admins… well, they are controlling morons who are afraid for their jobs and probably don’t know what the hell they are doing. I’ve work with SP for over 10 years now in various shops/environments. Invariably, it’s the places that lock everything down and keep people from taking advantage of SP’s features fully that ruin the usability and experience for all users. SP isn’t a perfect document management solution. It has many faults with which I’m very familiar. But the biggest proble with it by far are incompetent IT managers who don’t understand technology.
Sorry… obviously that’s my pet peeve.
You do have an option here. You can subscribe to an open SP 2013+ environement, hosted by Microsoft and available through any browser. It’s called O365 and it’s not very expensive as far as per seat licensing goes with plenty of online storage space and high availability. If your department manager can authorize the expense for your group. It’s would be a political fight but you can use that as leverage and tell your IT folks they can kiss your ass if they can’t provide you with the functionality that any consumer can subscribe for for as little as $9.99 per month.
I actually like the versioning apps that are aimed at code versioning and change control. Trouble is, they tend to be aimed at software developers/engineers and are not always as user friendly as some popular DMS apps.
If the OP’s IT department has locked down their SP environment to the degree that they have, it’s pretty unlikely they will release or install a code management system as an alternative for anyone who just wants to store and maintain some company SOP’s, etc.
SP is a good solution and quite simple if you go with the O365 solution (in the cloud). On prem gives more flexibility but is a major IT commitment in terms of maintenance and support costs.
Totally understand this. I’ve had both experiences but I have to say my experience with manual version control has scarred me for life. Scroll to the bottom if you want to read my sorry tale of woe (how bad can manual version control get? Well, let me tell you…)
Yeah, document or team workspaces. I checked and there is no ellipses, just a downward pointing triangle next to the file name and if I click it then I get a pull-down menu. Sounds from your description like we’re on SP2010.
Actually the people who have locked our SP down is a non-technical SP administrator. He’s a big SP bible thumper. The problem is that he’s a gatekeeper and he and his boss are very jealous of anything that can be construed as infringing on their “territory”. If I approach them sweetly and ask for certain things to be changed in our document workspaces, they’re happy to do them. They just don’t want US making those changes.
I actually like SharePoint but have many coworkers who hate it. This gatekeeper attitude does nothing to soothe the naysayers.
…
So, my sorry tale of woe with manual version control for anybody in the mood for a story:
I was a software engineer at the time, working for a shop doing critical real time 911 dispatching systems. It was Cobol and Assembler code running on Vaxes, Alphas and HP Integrity machines (depending on the customer). Every single customer had a customized system. So that we could support them, we’d take a backup of their system and restore it onto machines in our offices. Mostly we did small enough projects that one or two people could do the work, never infringing on each other’s changes. Occasionally we did have large projects that took more than six months to finish, and sometimes small projects would need to be done independently of the large project but be launched into production before it. When that happened, we’d create another version of the system for the small project, work on it, and then manually merge the file changes into the larger project.
After about a decade of this, I got kind of sick of it but convincing anybody we could use a CMS was swimming upstream. Meanwhile I got picked to be tech lead on a very large project that was porting the system from Vax to HP Integrity. The hard-core code changes (read: device drivers and such) were done on a copy of the customer’s system in our San Francisco office. When that was done, I had to copy the entire thing to our machine in our D.C. office. (So keep count here, that’s two copies of the system.) As my team of programmers worked on our local copy for a few months, the hard-core programmer in the San Fran office was also making changes to his copy. But didn’t tell me. When I found out, I had to merge those changes into ours. I also had to occasionally merge my coworkers changes into the local system when they worked on the wrong one.
When the Integrity hardware was installed at the customer’s site, we loaded a copy of our local system onto it so that it could be tested. (So, now three complete copies of the system.) After a couple more months, we had more changes on our DC office system to merge into the customer’s copy. Tested it out and worked well. Almost ready to launch to production, but the hard-core guy found a serious problem we didn’t know about. I didn’t know it at the time, but he fixed the problem directly on the customer’s system. Just prior to launch, I had to synchronize all three versions of the system to make sure that the customer had the latest and greatest. Because I didn’t know the asshole - I mean hard-core programmer - made his changes directly on-site, I inadvertently wiped them when I moved all our changes to the customer’s system. Didn’t notice it until we launched… and the thing crashed and burned. And I was the one pilloried for not correctly merging files despite the fact that the hard-core programmer should have made his changes to our system as well as the customer’s. No, it was all MY fault. I left soon after that.
