RE: [Codestriker-user] Feature request

[Matthew H. <mat...@wa...>]

David,

Your suggestion is what my secondary plan of action was going to be.
The developers will just need to create a topic for each time that they
commit, or do a diff between two revisions (beginning and end) and
upload that file (notwithstanding potential changes from other
developers will appear in the diff). This will have to be acceptable. :)

Kelly's process of committing to particular branches would really break
our current process. Not that your model isn't good, Kelly. It is just
different than our very established way of branching and producing
deliverables. :)

Thanks for the discussion. It's interesting to learn how other
organizations carry out the code review process.
I look forward to 1.8.0!

:)
Matthew

> There is an assumption in the Codestriker database that there=20
> is only a=20
> single diff change per filename in the patch file.  Patch=20
> files (and diffs=20
> files from all SCM systems) have this property.  I still=20
> maintain it would=20
> be confusing for a reviewer to see a diff chunk for more than=20
> one file,=20
> and then to see another diff chunk for the same file.  The=20
> diff files you=20
> are talking about would have to be created by a custom tool,=20
> they can'tbe=20
> created by the SCM system.
>=20
> A reviewer wants to see the cumulative code changes in one=20
> place, not in=20
> several places which would require them to mentally "merge"=20
> them together. =20
> Your provided example is very simple, and mental merging here=20
> is easy, but=20
> in a real-life scenario, I think it would be frustrating and=20
> error prone,=20
> especially if the second diff chunk makes changes made on the=20
> same lines=20
> of the first diff chunk.
>=20
> What about the process Kelly describes?  Does that suit your=20
> requirements=20
> better?  Another option is before a developer does a commit=20
> for unreviewed=20
> code, they still post a Codestriker topic, but it gets reviewed at a=20
> future time.  That way, if your process needs to commit code=20
> in the SCM=20
> now, you can still commit it, and it can get reviewed later,=20
> as the topic=20
> has been created.
>=20
> --=20
> Cheers,
> David
>=20
>=20
 =20
*************************************=20
This e-mail may contain privileged or confidential material intended for =
the named recipient only.=20
If you are not the named recipient, delete this message and all =
attachments.=20
Unauthorized reviewing, copying, printing, disclosing, or otherwise =
using information in this e-mail is prohibited.=20
We reserve the right to monitor e-mail sent through our network. =20
*************************************=20