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

Promotion Groups and private branches

From: Bicking, David (HHoldings, IT) <David.Bicking_at_thehartford.com>
Date: 2007-10-01 21:00:09 CEST

Two features that are important to my peers (and lacking in Subversion)
are Promotion Groups and private branches. Personally, I don't care
much for promotion groups, having used them in the past. However, I
would like to get some opinions from people here because this is one of
the more highly concentrated groups of smart SCM-aware people (and SVN
developers).
 
First, for the SVN devs: are these features on the docket? Are the
shelved due to a decision that they're not worth adding? Why?
 
What are the strengths of "promotion groups", weaknesses? I know from
working with PVCS that there is a danger of "automatic branching" at the
file level, which bothers me. However, with proper branching I suppose
it is avoidable. The way its usefulness was pitched to me was that it
allows developers to check-in as much as they want without "breaking the
build". Then, they can promote the files as they complete their unit
testing and otherwise feel comfortable with it.
 
I don't personally think the extra work is necessary (we're talking
about mostly collocated developers, usually teams of size five or less).
I also don't like the implication that we'd be juggling several
revisions of the same file in the codeline and mucking about between 4
promotion levels. It feels messy.
 
 
As for private branches, I see where this could be quite valuable. It
solves the problem of either complex public branching (to avoid breaking
check-ins to the mainline) or holding on to changes until one is rather
sure the checkin won't break the mainline build. The user would have
their own branch (invisible to all others) which they can update as much
as they like, then commit their changes to the mainline whenever they're
comfortable.
 
However, This increases change collision probability, it still doesn't
get rid of the possibility of programmers "leaving for the week w/o
checking in changes" (talk about a straw man argument - sheesh!) and I'm
not sure how the administration of this could be achieved efficiently.
Additionally, can users delete their branches? Can they be disallowed
to delete them? What about merging into their private branch? Do they
get one per public codeline? More?
 
The odd thing about both of these features is that they both add
complexity to individual developers' work. Yet, the lack of these
features is described to me as a problem because "not all developers are
as sophisticated as you". (huh?) So, I'm looking for honest pro/con
assessments. I think there is too much personal investment by people in
my environment to get objective opinions.
 
 
 
 

--
David Bicking
Heritage Holdings IT
55 Farmington Ave., Suite 605
 
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
Received on Mon Oct 1 21:00:47 2007

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.