www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matth...@offthelip.org>
Subject Re: [scm] Use case: Sequence of changes
Date Wed, 27 Feb 2008 17:40:23 GMT
A corollary of this use case (which is why I reply here instead of creating
a new thread) is when I want to commit without necessarily making my changes
visible to all or to be part of the main branch. You might call it a
temporary change.

Usually I don't want it to get into the main branch because its breaking
something (compilation, distribution, basic tests) and I need additional
commits to get to a stable state. The additional commit could come within an
hour or a week, it really depends (although if it's a week, it could be
argued that the work could be split). So why do I want to do this
intermediary commit in the first place? Because it makes sense as a separate
commit and I will want to track it as such later on.

One example would be to do some public API changes. Usually this will
involve 3 steps: changing the API, implementing and updating tests. I'd like
these 3 steps to be reflected in my commits, although intermediary commits
are very likely to break everything and block everybody else if I really
make them public.

To complement on the first point of variants and implementations:

a) The main problem I have with svnmerge.py (which is by itself pretty nice)
is that it's a separate tool from Subversion. I don't see why it's not
integrated in the standard Subversion command. The consequence is that its
command line is somewhat not so consistent with Subversion and also that it
requires separate upgrades from Subversion anytime the way the repository
format is changed (1.4->1.5). Maybe we could see with the SVN team if it
could be integrated as standard in SVN. And documenting its usage would of
course help a lot as well.

Cheers,
Matthieu

On Wed, Feb 27, 2008 at 7:53 AM, Jukka Zitting <jukka.zitting@gmail.com>
wrote:

> 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?
>
> BR,
>
> Jukka Zitting
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message