Why Use AccuRev for Document Management?

May 8th, 2008 by sshrev Leave a reply »

Let’s face it, process-centric SCM is not just about the process, code and issue tracking, it’s also about document management. Simply storing documents in a shared network space is no longer sufficient; documents related to a product release need to be versioned and tracked. We’re talking about a wide range of documents here — UML diagrams, meeting notes, functional specifications, wireframe prototypes, product plans, slide decks, planning spreadsheets, and, of course, end-user documentation from release notes to complete online help systems.

AccuRev’s stream-based, process-centric approach makes it easy to manage your product-related documents right alongside your code and issues. Add a couple of folders to your workspace — call them planning, doc, or whatever you like. Add your planning documents to the folders, and promote everything. Now your product documents are part of the stream.

  • When you create a child stream for the next release, those planning documents are included automatically because of AccuRev’s built-in inheritance. Just update the documents for the new release and promote. Product managers and others can create their own workspaces where they update those documents as needed.
  • Want to track general-purpose planning documents that aren’t related to a specific release? Create your child stream under the root, and store all those documents there. Create child streams and workspaces based on document evolution, not product releases.
  • Want to free your product managers and technical writers from using the AccuRev client interface? Now there’s the AccuBridge for Windows Explorer (for AccuRev V4.5.4 and newer), which provides AccuRev functionality from a right-click menu in Windows Explorer, and icon decorations to indicate AccuRev status.

Documents represent knowledge; they are part of the company’s history. They provide records of decisions and the context in which those decisions were made. They show the reasons behind the implementation decisions, the backtracking, the roads not taken, and the plans for the path ahead. When these important documents are not versioned and tracked, information is lost.

Advertisement

1 comment

  1. Chris Boran says:

    We have done this at Symantec. To combat the ‘we don’t want non-programmers accessing the source code’ we simply created a pass-through stream which explicitly included the documentation directories and excluded everything else. It worked great. We stored everything from QA test plans, Design Docs, Functional Specs, to burn down charts, bug statistics, and requirements. Since we ran long-cycle releases (9-15 month cycles) it was a real benefit to us to be able to look back and compare how estimates changed and tracked and look for trends when planning the next release. We learned a lot about how individual team members estimated (and over time, developed methods to try to compensate for individuals estimating flaws), and were better able to predict/plan the next cycle.

Leave a Reply

Anti-Spam Protection by WP-SpamFree