On Tue, Sep 11, 2012 at 04:48:12PM +0200, Laurent Alebarde wrote: > Le 11/09/2012 15:49, Stefan Sperling a écrit : > >On Tue, Sep 11, 2012 at 02:45:49PM +0200, Laurent Alebarde wrote: > >>Thanks for your answer Stefan, > >> > >>Unfortunatly, no : > >> > >>The first link says Subversion is smart with binary files. That's > >>good to hear, but do not provide a filter or filter hook between the > >>workspace and the repository. > >Apart from built-in properties such as svn:keywords and svn:eol-style, > >there is no way to make changes to files during checkout or commit. > >You can probably use a wrapper script for this purpose, however, > >that wraps svn checkout, svn update, and svn commit. > > > >What do you really need this feature for? I'm interested in learning > >more about your actual use case, the actual problem you're trying to > >solve, rather than what git's solution to your problem is. Maybe if > >I knew more about the problem itself I could give you a better answer. > >And maybe we can add some feature to svn to solve your problem, once we > >understand the problem. > Sure, you are right. At present time, my use cases are : > 1) Automatic coding style refactoring so that developpers remain > happy with what they are used to : indentation, naming, layout, etc.
In Subversion you can block commits that do not conform to policy by creating a pre-commit hook that evaluates changes about to be committed, and allows or rejects the commit based on that. This then requires developers to e.g. heed coding style to be able to commit. They could also use tools to modify files in their working copy before committing. I.e. the only difference is that there is no way to plug the "fix-up tooling" into svn itself, but that people are required to use this tooling in _addition_ to svn, before committing. However, if your pre-commit checks are too strict and there is no way to bypass them, people might end up not committing at all for longer than necessary, which is also bad. You should at least provide a way to bypass these checks (e.g. by putting a special marker into the log message) to allow for unforeseen circumstances where developers need to override these checks. > 2) Automatic doxygen comments generation. If this can be done in an automated way, why bother developer working copies with it at all? You could create an automated job that has its own working copy, updates to get new changes, makes any necessary doxygen modifications, and commits the result. svn can be scripted for these kinds of purposes. See the --non-interactive and --xml options that many svn commands support. > 3) Add information in the code in the workspace, from tags included > in the repository > The 2 first use cases need a filter between the workspace and the > repository. The 3rd one needs a filter between the workspace and the > internal or external diff. I don't think I understand 3), especially what diff has got to do with it. What is this for? Is this information meant for interactive use by developers while developing? Or is it some extended information of the sort that svn:keywords supports, which is embedded in files you ship to customers (outside the version control system)? In the latter case, you might as well use a separate working copy to add this extra information, and commit it from there, instead of forcing unrelated changes into developer working copies. I realise that git can easily hide modifications by automatically making them in the index instead of the working tree. So if you're adding information which developers don't really need to see on they fly while files are being added to the index, this doesn't bother them much. However, Subversion does not have a concept of an "index" like git does. There is only a working copy and a repository. So you're really talking about making edits to peoples' working files, which may or may not be desirable, depending on the use case. And keep in mind that developers might have their files opened up in editors while they run 'svn update' or 'svn commit', and you would be making changes to the files concurrently. I'd imagine that could lead to unexpected results. My advice would be to use automated jobs that use separate working copies, if at all possible, and leave developer working copies alone. They'll get to see modifications made by automated commits just like any other commits when they run 'svn update'.
