[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Best practice Q: when is it necessary to branch?

From: Noel Yap <noel.yap_at_gmail.com>
Date: 2006-03-28 21:35:47 CEST

Comprehensive answer: http://www.cmcrossroads.com/bradapp/acme/branching/

Caveat: IMNSHO, there's absolutely no need for a _developer_, as
opposed to _development_, branch.

HTH,
Noel

On 3/28/06, Matt England <mengland@mengland.net> wrote:
> Hello,
>
> I have what I call a "best practice" question:
>
> When is it necessary (or at least useful) to branch?
>
> Here's my current answers (or at least how my group has been operating thus
> far):
>
> 1) When one needs to do "side"/private development in a way that breaks the
> day-to-day builds of the trunk.
>
> 2) When one needs to make bug fixes of an old revision/tag of the repo
> (possibly by back-merging fixes/features in a future revision) without
> inheriting all the new stuff in the trunk.
>
> Is this a comprehensive and concise list?
>
> I realize this is a rather broad question (and possibly a faq somewhere),
> but I'm rather short on research time at the moment, so I seek guidance
> from the community.
>
> I believe I want to minimize the number of branches made in my repos,
> although I feel like I want to tag often (I review a "tag" simply as an
> alias to a svnversion number--sort of a read-only branch). Is this, too, a
> reasonable and effective approach?
>
> Thanks for any comments,
> -Matt
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 28 21:36:57 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.