Re: [Codestriker-user] Feature request

[David S. <si...@us...>]

> Basically, the only changes that I see that Codestriker would have to
> make is how it parses the uploaded diff file.
>
> Currently each developer needs to:
> - Create a diff file
> - Create a Codestriker topic (upload their own diff file)
>
> This would remain the same with my scenario. The only difference would
> be that the diff file uploaded in our scenario would contain multiple
> entries of the same file with different revision diffs.

There is an assumption in the Codestriker database that there is only a 
single diff change per filename in the patch file.  Patch files (and diffs 
files from all SCM systems) have this property.  I still maintain it would 
be confusing for a reviewer to see a diff chunk for more than one file, 
and then to see another diff chunk for the same file.  The diff files you 
are talking about would have to be created by a custom tool, they can'tbe 
created by the SCM system.

A reviewer wants to see the cumulative code changes in one place, not in 
several places which would require them to mentally "merge" them together.  
Your provided example is very simple, and mental merging here is easy, but 
in a real-life scenario, I think it would be frustrating and error prone, 
especially if the second diff chunk makes changes made on the same lines 
of the first diff chunk.

What about the process Kelly describes?  Does that suit your requirements 
better?  Another option is before a developer does a commit for unreviewed 
code, they still post a Codestriker topic, but it gets reviewed at a 
future time.  That way, if your process needs to commit code in the SCM 
now, you can still commit it, and it can get reviewed later, as the topic 
has been created.

-- 
Cheers,
David