www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <santiago.g...@gmail.com>
Subject Re: [scm] Use case: Sequence of changes
Date Wed, 27 Feb 2008 23:01:52 GMT

El mié, 27-02-2008 a las 17:53 +0200, Jukka Zitting escribió:
> Hi,
> 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
> steps.
> 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?

I'm using quilt in a similar case, and I'm now migrating to git-svn. It
is not in the ASF, the ASF is not friendly with git-svn, see separate
email I'm sending on that.

quilt is a nice small tool that keeps the changes as patches. While it
does nor properly merge, a workflow is like:

#have a patches dir with a series file containing the names of the
patches that must be applied in order.

svn status -u # changes pending? 
quilt pop -a # remove all patches
svn diff # should be clean
svn up # bring changes from upstream
quilt push  # first patch, it will fail if it does not apply
quilt refresh # when a patch applies but needs rebasing 
... # until all patches are applied
#edit some files and either
quilt refresh #if the changes touch a patched file
svn diff path/to/file >> patches/feature-N.diff # if not

rinse and repeat, occasionally comment or remove a patch from the series
file, or send it upstream, ...

While is doesn't do fancy merging and edits need to be added to the
patch by hand, the process is clean enough and the patches get rebased
progressively if svn up is done often. The patches themselves are not
versioned, unless you use mercurial queue or some similar trick.

mercurial queue (mq) is a mercurial extension (comes included) to handle
patches, with the bonus that the patches are versioned. 

I'm trying to get the same use case done by having one git-svn branch
per feature / bug. All the features/bugs would be rebased against the
remote trunk, and merged into a "mine" branch that would be the one I
typically run or test.

Santiago Gala

View raw message