Svn script to rename member variables to checkout / update
I'm working with a guy who prefers to name his member variables using the mCamelCase convention like: mSomeVar or mSomeOtherVar. I cannot stand this format. I prefer m_camelCase convetion like m_someVar or m_someOtherVar. We lead each other with insane glances at each other.
We've now added a new guy to the team and he prefers no prefix. Since we are using svn, we thought we could develop an svn script that renames member variables on the fly when you download code from the server. This way, anyone can get the member variables however they want.
Does anyone have any example svn scripts that can do this kind of thing? I've seen scripts that change the comment headers, but we need something that includes a C ++ processor.
Sounds like a recipe for disaster. To get this to work, you need to decide on a storage standard where each file uses the same variable naming conventions. If you can do that, why not just use all such codes ?! The important thing about conventions is not the convention you use, but everyone actually uses the same convention !
Find someone with seniority to make the call (or pull the rank if you can), everyone else will just have to suck it.
a source to share
I am assuming that you want to change the style for research purposes, and the question is just hypothetical. Joel S. seems to think that answers that simply say that you are doing something wrong are not good answers, so I will try to try and give you several ways to solve your problem.
The closest thing svn does in terms of conversions is change the line ending on checkout and change it on checkout. This allows the repository to have a single line termination idea, and for different clients to modify the files according to their preferences. While this feature sounds pretty straightforward, a number of people seem to have trouble getting it to work properly. Just google 'svn eol-style' .
Since svn does not provide any custom filters on the client side, I think it would be safe to assume that you would need to modify the svn client and compile it for your own purposes. Perhaps you can post the patch or extension back to svn.
So, at this point you need to download the svn source code and get it to compile the client. At this point, pay attention to libsvn_subr/subst.c
. This file contains routines for translating to and from various formats. He is currently doing keyword expansion and eol translation.
You just need to create a new property, possibly called member-variable-style
. For files with this flag set, you can invoke a custom conversion in your code subst.c
. You could track the reference in svn to the conversion code by looking at the calls to svn_subst_translate_stream3
.
OK. This was the easy part. Now you need to get a function to correctly translate the code from one form to another. You cannot just pull the cpp processor out of gcc because there is no guarantee that the code will be valid / compiled. You should do your best to create lexing rules that will hopefully do the right thing on the right variables. For varaibles starting with m_ or even m, this is pretty straight forward. Unfortunately, for a member of your team who doesn't use m_ at all, it can be quite difficult to determine that it is a member variable in C ++. Fortunately, there is quite a bit of human-driven research out there that creates syntax highlighting code. I would scramble through and find some code that does a good job with C ++ code.
Finally, since these conversions can get quite complex, I would suggest that at this point you have an svn shell for the filter. It wouldn't be great for performance, but it would be much easier to write and debug your filter. Then you can write your filter in Perl or your preferred language. For a good example of using an external external filtering program, see Squid redirectors .
Good luck!
a source to share
There are no hooks in Subversion that work with an update - you can have a post-commit * hook that allows you to convert from one convention to another (the repository standard), and you can use a script you write that checks out and then runs the necessary settings, but it will give you false readings on svn diff
etc.
My suggestion is to just sit with your colleagues and agree on a standard. The post-commit hook will still be useful to catch slippage.
* I think something that sees a commit has occurred, automatically checks and modifies the code to adhere to the standard repository convention, and then commits if necessary. Another option is to have a pre-commit binding that disallows a commit if the code is not standard compliant.
a source to share