{"id":620,"date":"2014-02-14T20:13:08","date_gmt":"2014-02-15T04:13:08","guid":{"rendered":"https:\/\/blogs.plm.automation.siemens.com\/t5\/Polarion-Blog\/5-Things-Most-Subversion-Users-Don-39-t-Know-Are-Even-Possible\/ba-p\/380809"},"modified":"2026-03-26T05:29:07","modified_gmt":"2026-03-26T09:29:07","slug":"5-things-most-subversion-users-dont-know-are-even-possible","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/polarion\/5-things-most-subversion-users-dont-know-are-even-possible\/","title":{"rendered":"5 Things Most Subversion Users Don't Know Are Even Possible"},"content":{"rendered":"

When Subversion<\/STRONG> came on the scene, it quickly became the market leading version control system, relegating all others to virtual obsolescence \u2014 something unprecedented for an open source product. But even as widespread as Subversion is today, most companies still have no idea about its potential to manage far more than just source code<\/STRONG>. If that’s all you’re using Subversion for, you’re definitely not leveraging all the power and potential SVN can deliver. Let’s look how you can get more from Subversion<\/STRONG>.
\n

The 5 Things Most Users Never Do With SVN<\/H2>
\n

    \n\t
  1. Use SVN to track everything<\/LI>
    \n\t
  2. Use SVN to create and manage traceability<\/LI>
    \n\t
  3. Use SVN to control your development process<\/LI>
    \n\t
  4. Pull info from your SVN repo for reports<\/LI>
    \n\t
  5. Use SVN to unify your entire development organization<\/LI>
    \n<\/OL>
    \nLet’s look closer at each of these “missed opportunities”.
    \n

    1. Track Everything<\/H3>
    \nYou know that SVN is great for versioning source code. So why stop there, as most people do? You can use Subversion to track every single artifact in your development process:<\/STRONG> requirements, defects\/issues, change requests, test cases, test execution results… what else have you got? You can track it with Subversion.<\/p>\n

    Take requirements<\/STRONG>, for example… or User Stories if you use Scrum or another Agile development methodology… or whatever you<\/EM> call them. The most common practice is to commit entire specification documents to a SVN repo, mainly because that’s better than nothing. But people quickly discover that managing the inevitable change<\/STRONG> from inception through implementation is a pain<\/STRONG>. Change one requirement in a Word doc, and you have a new revision of the whole document.<\/EM> It’s a tedious chore to find out what content was changed, when, why, and by whom. Change seldom involves the entire specification. Usually it’s just one requirement, or a few. So wouldn’t it be much better if you could version each single requirement in the specification document<\/STRONG>? Subversion can in fact handle this, but most SVN users simply don’t realize it.
    \n

    \"Requirement<\/A>
    \nClick image to enlarge<\/SPAN><\/DIV>
    \nThere are further difficulties with the “version the whole document” approach. What if you have a formal review and approval<\/STRONG> process? Assuming you get the right revision of the spec in front of all reviewers at the same time (which can be a good trick), you need to track who has reviewed<\/STRONG> which individual requirements and\/or the whole specification, who has approved or rejected<\/STRONG> which specific requirements (or the whole document)… and it would be good if you could capture comments<\/STRONG> when someone sends something back to the drawing board, wouldn’t it? Especially a year from now when you have to prove due diligence to a regulator in order to get e.g. your new medical device product approved for sale. The fact is: it’s possible to do all this with Subversion. <\/STRONG>We’ll talk about how later on.
    \n

    2. Create Traceability<\/H3>
    \nLet’s say you have requirements for something you are developing. Let’s further suppose you have test cases that verify those requirements. Let’s jump still further into the realm of conjecture and say you are so far advanced as to be versioning each requirement and each test case in your Subversion repo. That’s super, but so far there’s no linking.<\/STRONG> You can’t show that this<\/EM> test case verifies that<\/EM> requirement (or those<\/EM> requirements<\/EM>), or conversely, that this<\/EM> requirement is verified by that<\/EM> test case (or those<\/EM> test cases<\/EM>).
    \n
    \"Unlinked<\/A>
    \nArtifacts in SVN normally have no traceability. This can be remedied.<\/DIV>
    \nSame for any other relationships you might need to track… parent\/child, dependency, etc. Sounds like a database problem<\/STRONG>, doesn’t it? Certainly you could<\/EM> go that way… if you want to have yet another tool<\/STRONG> in the chain to be installed, administered, configured, maintained, etc. etc. Wouldn’t it be better if you could track this kind of information with Subversion?<\/STRONG> The good news is that you can. Traceability links, and the relationships they define, can be properties of any objects you manage in a Subversion repo. We’ll talk more about specifics later.
    \n

    3. Control Process<\/H3>
    \nWorkflow is a hugely important issue with impact ranging from team productivity to the company’s ability to compete. Most companies invest heavily in creating the most efficient process they can. They must not only define it, but also ensure that people know what it is and how to follow it. And it’s nice to automate, where possible. In regulated industries, it’s vital to have the process well documented, and controlled to ensure that nothing is ever missed or skipped. Again, there’s lots of information involved.<\/p>\n

    Imagine the benefits if that information could be leveraged in tools<\/STRONG> that would communicate about and guide people’s work<\/STRONG> so they don’t need to know the whole huge complex process, but just the steps they have to do. What if the same tools could track objects through the process<\/STRONG> so people always know the current status<\/STRONG> of both the objects (remember about requirements, tests, defects, etc.?), and the project as a whole?
    \n

    \"Polarion<\/A>
    \nUse SVN for workflow control. No need to know entire process… only possible next step(s)<\/DIV>
    \nAnd what if all that information could be handled by Subversion<\/STRONG>, which you already have and are comfortable hosting, administering, and using day to day? You may never have stopped to think that Subversion can be used as the central repository for this kind of information. But it can be. Again, we’ll see some solution specifics later.
    \n

    4. Report From Your SVN Repo<\/H3>
    \nIt shouldn’t be much of a mental jump to realize that once you have the kind of information we’ve been discussing tracked in a Subversion repository, it will be possible to extract different pieces, combine them in different ways, and output some highly useful reports for teams, managers, customers, and other stakeholders. The possibilities are limited only by your imagination and programming skills. (Well, what your boss wants to see might enter into it occasionally too.) The bottom line is information<\/EM>. Once you have it, you can buy or build tools to manipulate it in whatever ways you need.
    \n
    \"Report<\/A>
    \nWhen data is in SVN, it can be reported in useful ways. (Click for larger image.)<\/SPAN><\/DIV>
    \nAnd when it comes to developing software applications (and many hardware applications as well), Subversion can be the repository for every kind of information<\/STRONG> you need for you development process. Which segues nicely into our final point…
    \n

    5. Unify Your Development Organization<\/H3>
    \nAll too often, application and product development organizations end up with different functions in different, semi-isolated organizational islands. For example, one island conducts risk analysis and sends a document with their results to the island that develops requirements. On that island, there may be sub-islands for functional requirements and system requirements. The output of the requirements island (typically one or more specification documents… maybe actually versioned in SVN!) goes to the island that develops the application. That island may have a sub-island that develops and conducts tests (or that may be yet another autonomous isle).
    \n
    \"Islands
    \nA typical “islands” approach to application development<\/DIV>
    \nFrom a corporate management viewpoint, it can make sense to manage these islands separately. But in practical terms of getting product out the door (so revenues can flow in), this kind of separation usually makes life more difficult than it needs to be<\/STRONG> for all concerned. Let’s return to our core premise: that we can both store and track every kind of granular development artifact, along with its change history, its relationships to other artifacts, the process it is part of, and so on… all<\/EM> of this in Subversion (which you already have, right?)<\/p>\n

    Once again, it’s no great mental leap to envision the possibility of a common development platform and tool set<\/STRONG> that could be used to get all those various silos working much more closely and efficiently together. The same platform would enable the Risk Management unit to create Risk Analysis specifications containing granular Risk<\/EM> artifacts that define a hazard, failure modes according to FMEA, etc. – all stored in Subversion. These would be accessible via the platform (obviously it should be web-based<\/STRONG>) making the risk analyses (and the current Head revision thereof) accessible to the Requirements Management unit.<\/p>\n

    The Requirements unit works up the various functional and system requirements specifications, containing granular Requirement<\/EM> artifacts (or even subatomic types like Electrical Requirements<\/EM> or Hardware Requirements<\/EM>)… again, stored in SVN. Any of these can be linked via platform tools to any Risk<\/EM> artifact and the links stored in Subversion. Voil\u00e1 \u2014 traceability!<\/EM><\/STRONG><\/p>\n

    You can probably envision the extensions yourself: Requirement<\/EM> artifacts linked to Test Case<\/EM> artifacts, Test Result<\/EM> artifacts that link to the Test Case<\/EM>s tested as well as Issue<\/EM> artifacts resulting from test failures… just to cite a very few of the huge realm of possibilities.
    \n

    \"Traceability<\/A><\/DIV>
    \nEvery unit creates their brand of artifacts, and can link them to artifacts created and managed by other units. The platform could easily present visualizations, reports. Users could query for information in real time. Managers could always see the actual status and progress of projects, with data pulled from the Head revisions in the underlying SVN repository. It should be clear by now that Subversion’s potential goes far beyond simple source code version control<\/STRONG>.
    \n

    How To Make SVN Do All This?<\/H2>
    \nIf you’re still with us, you’re probably you’re asking yourself “OK, but how do we actually implement all this with Subversion?<\/STRONG>” Simple answer: you<\/EM> don’t have to because we<\/EM> have done it for you.<\/STRONG> All of Polarion Software’s solutions for     Requirements Management<\/A>, Test Management<\/A>, and Application Lifecycle Management<\/A>, plus our vertical solutions for Automotive<\/A>, Medical Devices<\/A>, and Agile Software Development<\/A>… all of them use Subversion in the ways discussed here, <\/STRONG>and other ways you may never have imagined possible. We can even do it in the Cloud<\/A>.<\/p>\n

    You can either merge any existing SVN repo with the one integrated into Polarion, or you can continue to use 1 or more SVN repos to manage your code base, and let Polarion’s integrated repo handle everything else, including establishing traceability to revisions in your external source code repo(s). To find out more about what Polarion’s solutions deliver using SVN “under the hood” (or “beneath the bonnet”), check out these links:
    \n