Dear Monks,
I'm a regular Monk here, but am posting anonymously. The problem at hand is that at work we have a 6 year old large Perl application that has never been refactored. It's undergoing quite a bit of bit rot, and is in need of architectural TLC. I've made a few moves to straighten things out by adding new files in a coherent manner, but each time I do so my boss yells at me saying that if we move too many files around then we will lose the file history (I clued him in on the Attic, but did not receive a warm response).
It's a well paying job, and I like my coworkers, but because we can't refactor or rearchitect the codebase, maintenance draws increasing amounts of effort. I follow the standard get bug report, write test, fix code pattern (and am really the only one who does it regularly), but I feel like we are stacking s**t higher and higher, and that eventually it will come tumbling down on us (I already get pieces of it bonking me on the head each day). It seems like once you make a mistake in placing a file somewhere with CVS, you have to live with it forever.
What would you do in this situation? Subversion makes this problem easy since you don't delete the file, but there's zero chance of migrating to that for bureacratic reasons. I'm interesting in the future of our codebase, and not so much in it's history. I know the history probably holds a certain amount of practical and sentimental value, but if you hang on to it too tightly it's almost like cement galoshes in some cases.
Thanks in advance,
Anonymous Monk
In reply to CVS history woes by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |