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.
Received on 2012-09-12 15:48:15 CEST