|
List Info
Thread: Promotion Groups and private branches
|
|
| Promotion Groups and private branches |

|
2007-10-01 14:00:09 |
|
| 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.
*************************************************************************
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.
*************************************************************************
|
[1]
|
|
|
about | contact Other archives ( Real Estate discussion Medical topics )
|