[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Encapsulating internal diffs?

From: Andy Levy <andy.levy_at_gmail.com>
Date: 2007-05-18 04:35:16 CEST

On 5/17/07, Olivier Dagenais <olivier.dagenais@formark.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
> """
> etc.
> 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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 18 04:35:35 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.