[Yanel-dev] Code review with Yanel

[Guillaume Déflache]

Hi!

Michael Wechner schrieb:
> Guillaume Déflache schrieb:
>> Michael Wechner schrieb:
>>> The second rule is that with "each" commit we add a "review file".
>>>
>>> The review file should be an XML and should describe which files 
>>> belong together and which version (in case it wasn't committed 
>>> atomically).
>>
>> Why shouldn't it be commited atomically? (Not doing it would make 
>> reviewing the changes harder anyway.)
> 
> for example when changing package name of a Java class. If I moved the 
> file and changed it at the same time, then SVN complained about it, my 
> maybe you have a solution to this

It works for me using a 1.5.4 Subversion command-line client. But I 
think this worked since long before that, at least say from 1.4, but 
also maybe even 1.3.
Commands used:
svn add svn_move_test.txt # svn mv source directories have to be under 
version control 1st
svn mv svn_move_test.txt svn_tests/ # do the move using svn, not using 
the filesystem directly
$EDITOR_svn_tests/svn_move_test.txt # make some changes here
svn ci
( see revision 41762 from https://svn.wyona.com/repos/ )


>> Where would we store these XML files? We would need to number them, 
>> delete the old ones, and similar bookkeeping, which is a lot of overhead!
> 
> agreed, but as discussed this morning if we use SVN hook for the moment 
> then it won't be any overheard except programming the hook
>> I think patches in Bugzilla is less of a burden.
> 
> because you don't use it ;-)

Maybe! ;) But I think review files would add a similar burden.


> Seriously I have received a lot of complaints that developers do not 
> like this approach at all (me neither ;-) and hence
> we need to find a better way, and I think the above is better :-)

Well, let's just try then!


> [...]
>>> Any objections?
>>
>> Well, see above and the "tomorrow-short" delay seems to call for 
>> overreaction! :(
> 
> I understand, but I want us to take action instead just keep talking 
> about it and the above suggestion seems to me a feasible try.
> If it shouldn't work out as expected, then we can easily switch back to 
> the status quo, but at least we gained some experience.

Sure, no problem.