Re: Encapsulating internal diffs?
On 5/17/07, Olivier Dagenais <email@example.com> wrote:
> > Any suggestions as to how to improve this? The CM process is
> > unfortunately unlikely to change---they still want us to submit diffs
> > rather than have direct commit access. But it would greatly help things
> > if there is a way of encapsulating a diff that effectively tells SVN,
> > "file X is actually derived from internal_url#1, so when adding please
> > reuse the history from that URL". Ideas?
> When we switched from VSS to SVN, we also implemented a single-committer
> patch submission and review process. When there are directory-level
> operations, they have to be documented in the change log that is submitted
> with the patch. We use a "File operations" section that describes what the
> committer must do, usually before applying the patch or even in the middle
> of doing so. (and there is usually a small enough number of operations that
> the committer can apply them by hand) It looks something like this:
> File operations:
> RENAME Project/Class.cs to Project/AbstractClass.cs
> Apply attached patch
> DELETE Project/DuplicateClass.cs
> In other words, your current tools and process are almost there. We
> recently started also using feature/task branches when there are several
> file operations as part of a commit (which was also mentioned by Giovanni).
> This approach also makes the reviews easier because the developer can commit
> as often as they want to their branch (sometimes within 10 minutes of a
> previous commit) and then the committer can inspect these changes
> individually or as batches. We also considered making the file operations a
> batch file that executes the command-line SVN program that performs said
> operations (because there really isn't that much more work involved than
> writing it by hand) but branches are good enough.
> If you go with the branches approach, take a look at "authz" (which appeared
> in version 1.4, I think) if you don't trust your non-committers not to
> commit to the trunk.
It's been available since at least SVN 1.2.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri May 18 04:35:35 2007
This is an archived mail posted to the Subversion Users