www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Justin Erenkrantz" <jus...@erenkrantz.com>
Subject Re: [scm] Use case: Sequence of changes
Date Wed, 27 Feb 2008 18:24:53 GMT
On Wed, Feb 27, 2008 at 7:53 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
>  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).

Why not?  Branches are cheap copies.  Subversion itself creates
short-lived branches *all* the time.

>  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?

Bidirectional merge (or as it is known in 1.5, 'reflective' merge) is
what you want and is fully supported now by SVN (through svnmerge.py
and is also part of the 1.5 merge tracking functionality).

http://www.orcaware.com/svn/wiki/Svnmerge.py#Merging_development_branches_back_to_trunk

Roughly (and untested), you would do something like:

% svn cp trunk branches/feature-x
% svn co branches/feature-x
% cp feature-x
% svnmerge.py initialize
% <commit changes to feature-x branch>
% ...review changes, iterate, etc, etc. all on branch...
% svnmerge.py avail -b
(-b is for bi-directional; that will tell you what revisions were made
on the branch that should be merged to trunk; it is also smart enough
to know that if you update feature-x against trunk later to omit those
revs.)
% svnmerge.py merge -b
...this will merge those revisions made on feature-x back to trunk...

>  b) The contributor is not a committer of the project in question. In

We have never targeted granting non-committers write access - and
that's 100% intentional.  If they are a frequent contributor, then
they simply should have commit access.  -- justin

Mime
View raw message