Can SVN do something like git filter attributes?

I'm not very familiar with git but it looks like it can use filter at开发者_如何学Gotributes to, for example, tidy XML files before committing. The SVN manual specifically (and strongly) advises against using pre-commit hooks for this. Is there another way?

The answer to this appears to be: no. I believe that rejecting the commit is the only safe option with SVN.

There's no other way to do it, and you'll find that doing such a thing even when it's supported will cause you nothing but headaches. Even reformatting code yourself before checking in isn't recommended because your revision diffs will not give you a good picture of what really changed. I only do it if something is so horribly formatted that it's unreadable.

The only place that you want to do anything like that is to use clean/smudge scripts to obscure you database connection string, password for a commerce portal, etc. This is usually done if you can have one config file and it is a mix of functional public data and private security data.

Pro Git Book's Attributes Section

hope this helps.

This sounds like a job for your IDE or XML editor. Eclipse for example lets you specify various automatic actions on save (but makes a poor XML editor)...I am sure there is an XML editor out there that will tidy or reformat your XML for you on save.

I don't think diffs should be a reason against this, because a good diff tool will have options for ignoring whitespace and/or unimportant differences, making viewing the diffs easy even if a file has been reformatted.

Depending on the team you work with, and if this "tidying" is dramatically altering every file you touch, you may want to avoid it or it may be perfectly alright. I for example have Eclipse trim trailing whitespace and add missing @Override annotations on save, but I do not tell it to fully reformat my .java files on save.

With Git, you have an entire copy of the repository for your personal use, so munging files during a commit them isn't a problem. After all, you're just affecting yourself.

However, Subversion has a centralized repository which means that munging files during a commit is trickier and is usually discouraged.

One of the issues is that this type of thing has to be handled by a hook, and hooks, since they run on the server, don't have access to your working copy. They can examine the commit via the read-only svnlook command, but that's it. Yes, there are ways to get around it, but as the manual said, it is not recommended.

Even with version control systems like Git and ClearCase where it is possible to munge files during a commit, it is still not a good idea. First of all, it can slow down the commit process as the hook script runs which can frustrate the user. Second of all, what happens if the munging process actually breaks the file? Developers are suppose to test and verify their changes before committing them. "Breaking a build" is a crime even worse than taking the last cup of coffee in the break room and not making another pot. Yet, here's a developer who did everything they're suppose to, and it was the stupid hook script that did it!

This is something that should be done by the automated build process (you are using an incremental build system like CruiseControl or Hudson right?). This can be done as part of the testing and the build can be marked as "unstable" if the file isn't formatted correctly. In fact, Hudson has hooks that can do this as part of the build process which makes doing this very simple. The build server can notify the programmer of his misdeed (Bad programmer! The file is poorly indented! No donut for you!) and the technical lead or the build manager.

What gets checked in is what the developer wrote and tested. Checks for formatting, unit testing, and all that other stuff can be done by the build system.