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 Re: [scm] Use case: Sequence of changes
Date Wed, 27 Feb 2008 19:09:17 GMT

On Wed, Feb 27, 2008 at 8:24 PM, Justin Erenkrantz
<justin@erenkrantz.com> wrote:
> On Wed, Feb 27, 2008 at 7:53 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
>  >  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.

Good point. Quite a few projects I've looked at use /branches only for
release and maintenance purposes and there is no clear place for
development branches nor practices on how they should be used. At
least I generally frown on development branches based on fear of them
evolving as forks of the codebase, but having short-lived and tightly
scoped branches sounds ok.

Perhaps some documentation about best practices on development
branches would be a good idea.

>  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

Cool, thanks!

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

This doesn't mean we shouldn't (or at least couldn't) make life easier
for non-committers, and also one area that IMHO many dSCM systems
currently do handle better than Subversion. It's probably not that
frequent use case, but still something to keep in mind.


Jukka Zitting

View raw message