Use SVN/GIT for Software Versioning history? Or something else?

Question

I'm currently working on implementing a versioning infrastructure for our in-business applications. You know, V1.1, 1.2 etc for our apps.

What I would like to do is have a simple setup of recording software changes and version history. We already use SVN (and moving over to GIT) and a part of me just says use that. But another part nags at me saying that that's not enough.

The Business don't really want to go through trawling our SVN repo, do they? I was wondering if someone knew of a better way of going about it? Any suggestions?

Thanks, Steve

Answer 1

I use a changelog to communicate bug fixes, changes, or new features to end users. I model my changelog on tortoisesvn which uses BUG: CHG: NEW:.

I place changelog lines in the repository history via commits, along with the more technical information that goes into commits. This joins the two tasks together in time, recording technical changes as well as what should be visible at a higher level to users.

When I release I can easily pull all the latest changelog lines and update the changelog/website/etc. With the prefixes on any changelog line in the commit history I can also automate it.

I like how this method keeps the two flows of information together, in the repository, where they should be.

Answer 2

Its been my experience that the commit messages usually contain highly technically details about the changes being committed. Generally they are not suitable for release notes. What I do is keep a more friendly 'release notes' document for this purpose. I am hoping to move over to a web based system like redmine that can track the enhancements and bugs.

If the commit messages are good (i.e. not to technically) there are ways to pull that information from the repo. For example here is the command I used to pull the messages out of svn:

svn log --verbose https://<address to server>/<repo name>/ > svnMessages.txt

Answer 3

You can use git in house and then simply make cuts out of the repository for major versions (tarballs).

Answer 4

I would choose the source control system that your development team prefers (leaning towards git if they're apathetic!). What you want is a standard method for 'publishing' a major version along with a changelog. This could be done with a script that downloads from the repository and displays the changelog, via a web-based system, it could just be a shared directory on the LAN, an FTP site, etc., etc.

Answer 5

Your question:

The Business don't really want to go through trawling our SVN repo, do they? I was wondering if someone knew of a better way of going about it? Any suggestions?

The extra information you provided:

A non-developer, maybe a member of Business from outside IT would like to know the changes that went into the last release, bug fixes etc. So you don't want to keep version history for business wide there, but maybe in a separate system

Separate System: Microsoft Exchange

Solution: Email them when a new release goes out.

Answer 6

All projects I work on have a wiki for use by developers and usera. The wiki is mainly used for documentation/help but it also includes change logs suitable for end users. The change log is updated daily, referring to version control if required, with final edit and polish when the build is released.

Many users, especially the bill payer when working remotely, appreciate the daily updates.