Le 12/09/2012 13:30, Stefan Sperling a écrit :
On Wed, Sep 12, 2012 at 11:40:58AM +0200, Laurent Alebarde wrote:
So the best way for me woudl be to use a "dummy" workspace copy
before commiting, and another one after check-outing :
WS ---pre-commit-treatment-(git-clean)---> dummy WS ---commit---> Repository
Repository ---check-out---> another dummy WS
---post-check-out-treatment-(git-smudge)---> WS
You might be able to do this kind of thing with git.
But I doubt you'll get it working nicely with Subversion.
Why don't you use git? Now that I know more details, it seems
that git's solution fits your problem much better. It is not
something we can easily add to svn because we don't have a
separate stage between the working copy and the repository.
It seems something like that would need to be added to svn first.
I do use Git, but I have to use SVN too. The idea above with
"pre-commit-treatment-(git-clean)" and
"post-check-out-treatment-(git-smudge)" is something outside SVN, or
something that encapsulate SVN.
As code in each developper WS is not standard, I cannot diff code
from a WS and the repository directly. Files have to be in the same
referential. So either I "smudge" the file coming from the
repository before diff-ing it with the file of the WS, either I
"clean" the WS file, before diff-ing it with the repository file.
I think that's a horrible solution to the problem.
IMO, developers should work as a team, and thus also agree on
common coding and quality standards. No technical solution should
be used to resolve differences in matters of taste, or worse, cover
up mistakes made due to sloppiness.
It is a question of taste and point of view. I agree my opinion is not
widespread, but I support it.
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)?
Yes, for my 3rd use case, svn:keywords does the trick. Thanks. But
svn:keywords are not enough though to solve my diff paradigm above.
It does. Since you have a way to automatically change coding
style in files, you can perform that transformation in a diff
tool wrapper script. You could write an external diff tool that
takes the files from svn, normalises them, and then diffs them.
Yes, I have to encapsulate everything.
Thanks a lot for your help.
