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'.
Received on 2012-09-11 17:58:43 CEST