Is Subversion Too Hard?
May 21st, 2008 by TasticSubversion seems makes a very good amount of sense. It has some drawbacks and some benefits. Some developers prefer different models of source control, some companies only use certain source control systems, but everybody on the same page that it is simple enough to understand and use, right?
Well, maybe not. People who are not familiar with the concept sometimes have a great deal of difficulty getting over the first few steps. There are tools like Tortoise SVN can help a great deal in instructing users, but there still remains the question of if it is suitable people who are not developers. Ah, there’s the key. You were probably wondering why someone wouldn’t suck it up and go read the book. Well, at the company I work at we exposed subversion to everyone, not just programmers. People who work with the software configuration, the reporting tools, and files used in data conversion are all instructed to use the repositories. We had to create rules to were the files go, I’ve had to help people with sandboxes they’ve broken, instruct them on how to use the tools, and fix their mistakes. The company is pretty small so I’m not sure we could handle a more controlled process that doesn’t require giving them control of the files, but I’m becoming less sure that introducing the concept of a code repository was a good thing.
Before we had file shares to hold most of this data. That had problems with tracking what was changed or accidentally deleted, but it was simple. Well, it was simple until they decided to start “versioning” the files with dates in the name or having more than one person working on the configuration at a time. So we brilliant developers smacked them and told them to just use the repository instead. However, it still took time to break them of putting dates in the filename, and they are not putting in meaningful log messages, so tracking changes is still a problem.
Now I’m wondering if the file share was a better concept and just have a nightly automated task suck the files into the repository, but I’d lose the ability to see who done what. What I think I really want is to have a single developer to be the point of contact for all official product configuration changes. This would cause much better review and tracking ability, but that’s more resources than we can afford to spend.
One thing I am sure on is that you should maintain separate repositories. The muck is also in the same repository as the code, which might be why this is my problem instead of the technical leads in implementation. Sigh.
Cops & Robbers