3

I am looking into an alternative for the combined utilities of SVN, as both a development tool and configuration management tool. Instead, I would like to investigate the approach of having a dedicated Configuration Management (CM) tool and a separate development tool.

The reason for this is that I work in a company where a lot of non-programmers use the SVN for CM, and I think it becomes confusing to them when the programmers use SVN for development alongside of CM. Additionally they get frustrated with the overlap of capabilities, and don't like the prospect of reverting to non-working versions. Separating these functionalities into two separate tools may provide ease-of-use for the non-programmers, that only use SVN as a CM tool.

So what approach would you suggest to achieve this? If you have experience with this what utilities have been useful to you and what were your results regarding clarity of processes and general workflow?

Note: IMO using SVN for both is best, but since the programmers only make up 20% of the usage for SVN, producing a more widely accepted process throughout all groups may be worthwhile (or at least worth looking into, hence this post).

Thanks

Edit- The typical non-programmer commits their working loads to the SVN repository. Then, as the customer deems a version to fix/not-fix the issue, the versions are reverted or updated. They don't want files that result in non-working exectuables to ever be in the SVN. Hence, reverts would most likely be done one revision at a time... not from revision 142 to 89, for example. So essentially they want a utility that only has the /tag work.

Improve this question
4
  • Could you step through what the non-programmers actually do with SVN? Like what's a typical use case?
    – chrisaycock
    Commented Mar 3, 2011 at 18:07
  • @chrisaycock I have edited the question body to answer this.
    – ToTheBeach
    Commented Mar 3, 2011 at 18:12
  • Isn't reverting the revision kind of antithetical to doing SCM?
    – Wyatt Barnett
    Commented Mar 3, 2011 at 20:39
  • @Wyatt Well the SCM is for keeping working released ordered. Maybe a new working version isn't acceptable to the customer, so it is necessary to revert back the the previous release.
    – ToTheBeach
    Commented Mar 4, 2011 at 11:27

2 Answers 2

Reset to default
5

Suggestions

1) Use two different SVN repositories.

2) re-structure the current (I'm assuming, single) SVN repository to:

/cm/trunk/
/cm/branches/
/cm/tags/
/project/trunk/
/project/branches/
/project/tags

3) If the CM is specific to the project:

/project/dev/trunk
...
/project/cmd/trunk
...
Improve this answer
2

A continuous integration app like Hudson can work along with SVN to automate creation of tagged working builds and provide a nice web UI for navigating to older ones. Non-techie users would not have to use any SVN commands directly to access different builds.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.