Le 11/09/2012 17:47, Ryan Schmidt a écrit :
On Sep 11, 2012, at 09:48, Laurent Alebarde wrote:
Le 11/09/2012 15:49, Stefan Sperling a écrit :
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.
The usual Subversion solution for this is to either
a) write a pre-commit hook that verifies that the code conforms to the style
guidelines, and rejects the commit if it does not; or
Our policies are : "developpers feel like at home" and "tools shall
adapt to developpers". I recognise it is unusual and dissonant. So
developpers use their coding style they are efficient with and I
translate that to something standard. I induce the rules to provide the
developper with something he could have written himself when check-out.
I could find examples of pre-commit hooks, for example to convert
indentation from spaces to tabs or the opposite. Then I could find the
lists of available hooks in the documentation. If I am not mistaken,
there is no hook available in the opposite direction, say in the
check-out process ?
b) write a post-commit hook that converts code to the required style and
commits this in a second revision
2) Automatic doxygen comments generation.
Here too the usual Subversion solution is to have a post-commit hook generate
this and then commit it. Another common answer is that things that can be
generated should not be stored in the repository.
I agree with you, except in the case of a heavy process, though another shared
storega place can be found instead of the svn repository. But keeping it in svn
anable to apply patches of manual updates from versions to versions. I mean the
documentation is only around 75% automatized.
3) Add information in the code in the workspace, from tags included in the
repository
I don't understand... could you give an example?
Please, cf my other answer in a separate message.
