Is this possible? If so how do I do this?
The code is in C# and we are using TortoiseSVN.
I simply want to auto format the code on every checking.
Thanks a lot
+6
A:
I think you can do this using a pre-commit hook in your repository.
Edit To the people who think this a bad idea (I'm not saying it isn't): It's not uncommon for organizations to enforce a specific code style or code formatting. Sometimes these rules can be quite pedantic and strictly enforced, and although they are usually human actions involved in this (i.e. formatting to the correct style before you commit anything to the repository), automating the process can sometimes be useful.
An alternative approach might be to do the verification automatically before the commit, but still allow the commit even if the check fails, but then only send an e-mail or some other notification to indicate that someone didn't follow the style.
Anders Sandvig
2009-06-19 13:32:38
+2
A:
It is possible, but also a very, very bad idea.
No automatic code formatters are perfect, and I can almost guarantee that it will tick people off.
That said, if you want to do it, look into using pre-commit hooks.
Is the SVN server running on a Windows or Linux system? And what code-formatter do you want to use?
David Wolever
2009-06-19 13:32:50
I'm looking at NArrange (http://www.narrange.net)
SuperSuperDev1234
2009-06-19 13:34:48
Yeah, does not sound like a good idea to me either. Some discipline on the part of the coders is MUCH safer than broken code.
crashmstr
2009-06-19 13:34:57
In that case I can't help much... I don't know much about Subversion on Windows... But it seems like @Yoopergeek has you covered there. Anyway, one thing you might want to consider is, instead of adding a hook, write a script so devs can easy format their code. Then, if there is ugly code checked in, you can politely ask them to use the tool.
David Wolever
2009-06-19 13:46:00
+13
A:
You're touching on holy-war ground. Mussing with people's formatting is asking for pitchforks and torches.
My recommendation: Don't.
Not to mention, if you're talking C#, and your developers are using Visual Studio, VS has a lot of auto-formatting tools. Just by entering that closing curly-brace and VS can/will auto-format your code.
A better solution may be to get all your developers to use the same auto-formatting settings. Tools->Options, Text Editor->C#->Formatting. These settings are exportable, so if you can get the team to agree to use the same code-formatting settings in VS, you can avoid the trouble of performing it in your source control system which is better left to do what it does best.
If you're hell-bent on doing this, a pre-commit hook, like others have said, is the way to go. If you're SVN server is running on Windows, might I recommend CaptainHook for writing your hook scripts? Plugin-able hookscripts that you can write in any .NET language.
Yoopergeek
2009-06-19 13:34:47
Entirely agree – check code-formatting options into the repository, then everyone can share them.
David Wolever
2009-06-19 13:47:09
Woah. Until you just stated it, it hadn't occurred to me to include the exported VS formatting settings with the project in source control. That's a good idea.
Yoopergeek
2009-06-19 13:55:48
+16
A:
With a pre-commit hook script, you could do that, yes. But I'm sure that you will remove that script after the first commit because you'll get into big problems.
If you modify the data that gets committed, the client doesn't know about that. So after such a commit where your script 'fixes' the formatting of a file, the file content in the repository is different than the files in your working copy. But your working copy still thinks it's up to date with the repository (after all, it's modifications just got committed).
So on the next update, you'll get into hell - broken working copy, angry users, ...
And of course, you might break the build - auto formatting has that effect sometimes.
You can of course implement a hook script that checks for a correct formatting and returns an error if it doesn't, that's perfectly fine.
And since you're using TortoiseSVN, you can try doing the formatting in a client-side pre-commit hook.
Stefan
2009-06-19 13:44:20
That is the best reason to **not** to do this : repo<->working-copy inconsistency. Very good point.
Yoopergeek
2009-06-19 13:46:18
The conflict/stale working copy issue is no different than if anyone else committed a new version of a file to the repository. This will be resolved by getting the latest version from the server, and if the user forgets, the svn client will detect this when trying to commit the file again.
Anders Sandvig
2009-06-19 13:50:21
I think the trouble, as Stefan is stating, is that, by committing, you are thereby forcing the commit-er into having to update immediately after they commit because the pre-commit hook will have changed their code.
Yoopergeek
2009-06-19 13:54:49
No, an update won't fix this. An update will get the differences between the revision the working copy files are at and the repository. But since those are the same, an update won't do anything.That's why I said that the working copy gets broken.
Stefan
2009-06-19 14:24:43
If you make changes the content in the pre-commit script those changes will get sent back to the client. Key word replacement for example indicates that this will happen.
Michael Wiles
2009-06-19 14:38:47
Nope, such changes are *not* sent back to the client. Keyword replacement is done on the client side *after* a commit, but to do that the client only has to know what it has sent to the repository, not what the repository has done with it. Of course, the repository sends the resulting revision back to the client, that's all that's needed for keyword expansion. But the repository does not send back changes a hook script has done.I know what I'm talking about here, believe me :)
Stefan
2009-06-19 15:00:19
@Michael Wiles:you probably have some custom SVN build then.The only way I can get the pre-commit hook changes to the client who committed them is "commit->update to a lower revision->update back to HEAD"; otherwise the client thinks "I already have the HEAD revision, no need to update" and therefore won't get the changes that your hooks have made.OTOH,if every (real) commit invoked the formatting change and another automatic commit,that could work (but would lead to impractical workflow: "commit->wait for the automatic reformat and re-commit->update to reformatted version"); caveat loops.
Piskvor
2010-02-21 15:16:25
+2
A:
like most people here I agree adding a pre-commit-hook that rewrites their code is bad, however you can have a pre-commit hook that rejects code that is not formatted to your coding practices and inform the user of such error.
mog
2009-06-19 14:46:40
A:
I highly recommend it.
Use a pre-commit script or better still, find a way to do it automatically in your IDE (pre-commit will push the changed file to the client). Eclipse can auto format on save.
The rationale for this is that if developers format differently you'll find files which have commits on them where the commit is only a formatting change and it will cause endless confusion.
A common formatting pattern is a very good idea. It'll be hard to introduce, but it'll be worth it. All changes will be real changes, and not just formatting changes. In my experience developers will see the benefits and accept it.
I've worked with cvs and java and used jalopy to auto format. We were using a branching system so it was mandatory, and it worked very well.
Michael Wiles
2009-06-19 14:55:45