Once upon a time I worked at a company, say "Super Research Company (SRC)". The software was housed in a Subversion repository, which I had read access to and could see the logs. As part of the code review process, the manager (call him George) required all proposed checkins be emailed to him as a patch against the trunk. Should they be accepted, he would go ahead and check them in. George liked two things:
- Making sure all code "was written with such consistency that you couldn't tell who wrote it."
- Going on two week long business trips.
This led to the following remarkable characteristics of our software project:
- Code took on average 1 week to get reviewed from the time of submission.
- Checkins contained approximately two weeks worth of work.
- All checkins showed the same author in the log, so no one knew who to talk to in the event of a problem.
- About half of all checkins were rejected at first submission due to something like a comment having one too few indentations. I spent about 2/3 of my editing time in WinMerge looking for subtle indentation inconsistencies (there were detailed rules about vertical alignment for multi-line expressions).
Your proposal may show only one portion of this, but the horrific experience is so etched in my mind that I must warn you to seriously consider the ramifications of your decision.
That said, Subversion patches can be useful for projects receiving one-time submissions from external users, etc., so I don't think the idea of sending patches is conclusively wrong. :)