www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject [scm] Use case: Sequence of changes
Date Wed, 27 Feb 2008 15:53:52 GMT

Here's a use case that I encounter every now and then:

A contributor wants to submit a code change that is best described as
a sequence of dependent changes. For example many refactoring
operations consist of a number of simple and easily verifiable steps,
but when combined the resulting patch can easily become large and hard
to review. Often the individual steps are also only meaningful as a
part of the larger change.

It would be nice to be able to present such changes as a sequence of
patches instead of one big patch. It should not be necessary for
someone to review and apply each component patch before the next patch
in the sequence can be created.

Such a sequence of changes doesn't need to be the result of a huge
forked development effort. Even an hour of refactoring for a tightly
scoped improvement can end up producing a patch that would be much
easier to review if it could be split to a sequence of incremental

Variants and implementation options:

a) The contributor is a committer of the project in question. The best
way to handle such cases with our current version control
infrastructure would probably be to create a temporary development
branch of the project, apply the sequence of changes in the branch,
and then propose that those changes be reviewed and applied to the svn
trunk. However, many projects don't have any good place for such
temporary branches (that might be used for just a few hours or days).
Merging such changes back to the project trunk is also a bit
cumbersome. Perhaps we should document (contribute to Subversion) how
to use tools like svnmerge.py to better handle such cases. Also, how
will the merge tracking feature in Subversion 1.5 help us?

b) The contributor is not a committer of the project in question. In
this case our current version control infrastructure doesn't help
much. The only way to achieve this use case would be to load the
project sources to another version control system and use that to
produce the sequence of patches. What would be the best ways to do
this? Can git-svn handle this? How about svk or a vendor branch in an
independent svn repository? Are there any plans in Subversion to
support such cases? Something to consider for Subversion 2.0?


Jukka Zitting

View raw message