7

I have a bit of experience with SVN as a pure programmer/developer. Within my company, however, we use SVN as our Configuration Management (CM) tool. I thought using SVN for development at the same time was OK since we could use branches and the trunk for dev, and tags for releases. To me, the tags were the CM part, and the branches/trunk were the dev part.

Recently a person, who develops high level code (but outside of the "pure SW" group) mentioned that the existing philosophy (mixing SVN for dev and CM) was wrong... in his opinion. His reasoning is that he thinks the company's CM tool should always link to run-able SW (so branches would break this rule). He also mentioned that a CM tool shouldn't be a backup utility for daily or incremental commits. Finally, he doesn't like the idea of having to jump from revision 143 to 89 in order to get a working copy... and further that CM tools shouldn't allow reversion to a broken state. In general he wants to separate the CM and back-up/dev utilties that SVN offers.

Honestly, I am new and the person with this perspective is one of seniority, experience, and success, so I want to field this dilemma with the stackoverflow userbase to see if his approach has merit.

My question: Should SVN be purely used for development, and another tool for CM (or vice versa)? Why? If so, what tools would you suggest for this combo? Or do you think that integrating both CM and dev into SVN is the best approach? Why?

Thanks.

Edit- during my research I found the following site which may give some more reasons against using SVN for CM. Are the author's points valid? I feel like this is aligned with what my colleague was inferring...

Link: SVN isn't CM

Improve this question
4
  • 2
    What's CM in this context?
    – Adam Lear ♦
    Mar 3, 2011 at 15:37
  • 2
    You are using subversion the way it was designed to be used.
    – Mumbles
    Mar 3, 2011 at 15:42
  • @Anna CM is configuration management. The question body has been edited to reflect this.
    – ToTheBeach
    Mar 3, 2011 at 19:30
  • You need to distinguish CM (configuration management) and VC (version control) which are pretty different areas even though VC is very often considered to be a subset of CM
    – altern
    May 13, 2013 at 13:09

4 Answers 4

Reset to default
9

I think the better question is: Is what your doing now currently working for YOU? Alot of "experienced" programmers are quick to jump and say what is wrong and what is right, but sometimes what is right for them might not be the best for you.

Just something to take into consideration, IMO if what your doing now is working well, I see no problem with keeping that.

Improve this answer
2
  • Well its not just about me, its about 65% of the company (these people all adhere to our SVN policy, including the person who thinks the current way is wrong). Your comment is along the lines of what I am trying to dig into, though. Since non- "pure SW" people use SVN at our company, is it reasonable to diverge into two separate tools in order to increase simplicity by having two distinct tools with two distinct purposes? Do the pros of this, in your experience, outweigh the cons?
    – ToTheBeach
    Mar 3, 2011 at 15:52
  • Well we basically only use SVN in my job, but the applications I write are quite small. I was more just saying what I was saying as just kinda a basis when it comes to someone using something that you were used to using something else.
    – user6791
    Mar 3, 2011 at 16:36
2

We use SVN for developmelemnt and CM . We tag the working copy . I personally don't see any problem in that . What is the problem in jumping from revison 143 to 89 or whatever?.

Improve this answer
2
  • He thinks that CM should mean jumping from one working revision to the next. Reverting a file from rev. 143 to rev. 89 introduces guesswork when trying to get a working project (maybe rev. 112 was a mid-stage bug-fix update that would break the runtime .exe).
    – ToTheBeach
    Mar 3, 2011 at 15:47
  • 3
    So just tag "working " releases and revert from tag WORKING_RELEASE_143 to WORKING_RELEASE_142 and forget the revision numbers
    – JohnB
    Mar 3, 2011 at 16:45
1

The points he makes are fair as those features don't belong in a CM tool. BUT SVN is not a standalone CM tool so it has these features and you need them for the daily development aspect.

If you use SVN tags just for working builds and nothing else then all the problems he poses won't apply to the tagged versions and anyone looking for a working build shouldn't have to go near trunk or branches. Put incremental numbers in the tag names like RELEASE-1.0.12.

Using this approach tagged versions will always be run-able SW, they will have incremental numbers and they aren't involved in daily backups. Can he come up with have another reason for using a separate tool?

In summary keep the following pattern and you'll be fine using SVN for both:

trunk + branches = dev

tags = working builds

Improve this answer
1

It kind of sounds like he's not familiar with your conventions. If he needs to use something (as opposed to work on something), then he should grab from a tag. If he needs the latest version of the code, then he needs to check out a branch. This is really the way almost any SCMS works.

Does he give any indication of what he considers to be a "proper" CM system? Perhaps he's looking for something that sits outside Subversion and manages builds and releases, with some kind of process that promotes files based on some kind of status continuum (dev -> test -> release). This is what comes to mind when I think of CM, but not many shops seem to do this anymore.

It sounds like your current method is reasonable, I think there may be some unspoken subtext behind his attitude.

Improve this answer

Your Answer

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

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