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

code promotion / changeset deployment process - best practices?

From: <ed.wittmann_at_fiserv.com>
Date: 2005-03-15 16:23:51 CET

I'm currently managing the source code environment for several projects at
my company. Previous to this job, I had managed code using Merant PVCS.
Now I'm using VSS. I had successfully implented and maintained a
development process for 30+ developers using PVCS, event triggers +
scripts, and the promotion model - this worked out pretty well, but there
were definately some drawbacks, the PVCS I-Net client (which was quite
nice), but that meant no IDE plugins, the GUI client sucked, hardcore.

I'm investigating Subversion as a replacement for VSS, but the environment
is very different (not bad!) than either of the other packages I've
previously used. I'm very used to the lock/change/checkin model that is
the default for VSS and PVCS, so the branch/merge model that is Subversion
is new to me.

Could someone who's made a change like this help give me a bit of

For instance, it's *very* important for my current job to identify and
promote to the production code branch only that code which is part of a
defect scheduled to be implemented. I understand that Subversion does a
very good job of identifying these changes, but it's the implementation
that has me wondering. Do I allow developers to branch whenever? Is each
changeset it's own branch? Or do I limit branching, and simply merge
specific revisions?

if I have this model:

trunk ->
------------ testing ->
--------------------development ->

And my process is given as thus:

- developer-created branches can only be merged with the development
- revisions to the development branch are merged with the testing branch
for pre-release testing;
- only revisions to the testing branch will be merged with the production

Does this make sense? Or am I making too much work for myself here?

Edward Wittmann

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 15 16:26:46 2005

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.