Le 11/09/2012 17:58, Stefan Sperling a écrit :
> 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.
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
> 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.
One idea behind all that is I don't want to block at all.
>> 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.
Please, cf my other answer in a separate message.
>
>> 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?
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.
>
> 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.
>
> 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'.
Yes, but I am afraid to be obliged to encapsulate many svn commands, at
least diff, to integrate the whole "smudge/clean"process.
Received on 2012-09-12 11:42:00 CEST