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 19:50:49 GMT
On Wed, Feb 27, 2008 at 11:09 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
>  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.

This is more of a social problem than a technical problem.

You can see how many branches SVN has:

http://svn.collab.net/repos/svn/branches/

You could create a 'release-branch' directory and a 'feature-branch'
directory.  But, there's nothing intrinsic to SVN about the
'tags'/'branches'/'trunk' names.

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

FWIW, Chapter 4 of the O'Reilly SVN book has been rewritten to
incorporate the new 1.5 merging paradigms:

http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html

Karl's book is also good with respect to branches:

http://producingoss.com/en/vc.html#branches
http://producingoss.com/en/release-lines.html

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

I believe our first priority should be to support our committers.  =)  -- justin

Mime
View raw message