I started in a new job almost two years ago now and the SVN repository process was already existing. That process came to be what it is because there was never much thought put into the best forward-looking way to leverage SVN to manage the codebase. Now we're in a situation where we need to make a change before we grow much more. We're looking for a better way to use SVN suited to our needs.
There is code across all these repositories which sometimes overlaps in the /var/www, /usr/local, /opt directories and their subdirectories.
Up to now we've managed this by doing our changes in the working area of the server (/var/www, /opt, /usr) then moving all our changes and their directory structure over to a working copy in our home directory where we can perform our svn operations on those files.
I've done some experimentation with checking out the repositories over the root of the server but then I have to sudo all my svn operations. The other concern is that if I switch to repository-for-customer-a and I have to make changes to the base framework then are those changes being tracked? Will they be included in the svn stat of repository-for-customer-a? Or if I do an SVN commit will the server commit files to both repositories at once?
Managing the SVN the way we do is totally inefficient and a liability because often there will be files missed which are essential to a fix/change and when it comes to merging code back to the trunk we aren't making use of the SVN branching/merging so it's a lot more work for our gatekeepers. There is a lot of overhead in our processes which can be eliminated here if we can just figure out how to leverage SVN the way it was meant to be used.
I've come to Stack Overflow because I greatly respect the format and the community here. Any advice is greatly appreciated!
Your workflow will improve a lot if you distinguish clearly between source code and installed program. Code should flow from a source location (that has no production relevance) to the installed location, as in:
http://your-svn-server
| checkout
v
/home/local-checkout
| make install
v
/var/www /opt /usr
Make sure that code never moves up in this hierarchy, except through svn commit
. Especially, don't monkey-patch /var/www and then copy the files into your checked-out directory. You'll never copy all the relevant changes.
This sounds like a lot of work, but it isn't. A make install
script usually takes very little time to run, especially when no compiler is involved. On the upside, the defined deployment procedure helps you greatly in the future when you want to migrate to a different box or just generally install anything on a new machine.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With