code promotion / changeset deployment process - best practices?

[ed...@fiserv.com]

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 
perspective? 

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 ->
------------------------------------developer-branch1
------------------------------------developer-branch2 

And my process is given as thus: 

- developer-created branches can only be merged with the development 
branch;
- 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 
trunk;

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

Re: code promotion / changeset deployment process - best practices?

[Tom Mornini <tm...@infomania.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 15, 2005, at 11:22 PM, oleksa borodie wrote:

>> I'd recommend this:
>>
>> trunk
>> branches
>>    issues
>>      issue(id)
>>    maintenance
>>      maint(id)
>> tags
>>    trunk(id)
>>    maint(id)
>
> Could you give me the difference between 'issue' and 'maint' please.
> I thought that developers work on the branch together and merge
> changes to trunk.

The issue branch structure is formally known as a task branch. It  
isolates
a single set of changes for a particular task, which makes it easy to
integrate certain fixes or enhancements into the trunk or maintenance
branches.

This allows for developers to commit as often as they like without  
polluting
the trunk with code that hasn't been reviewed and/or doesn't work. Only  
after
review or testing do the changes get integrated into trunk or maint  
lines.

The trunk would be the most current "best" integration. maint branches  
would
be made immediately upon or slightly in advance of a release, allowing  
the
trunk to stay active for future development.

> Is there any 'The best practice of' concurrent develepment with  
> Subversion?

Well, there are several books written a long time ago that work as well  
for
Subversion as they do for any other versioning system.

One that I really like, by a participant of this mailing list no less:

http://www.amazon.com/exec/obidos/tg/detail/-/0201741172/102-2379156 
- -7960160?v=glance

- -- 
- -- Tom Mornini
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFCOGn1zaKkuvKwKvcRApcfAJ9sxZWH/N3BFPHFe0f99yZKkfHagwCfV9fR
t3izGGZIYe6/lhWo95yK0bw=
=+VjL
-----END PGP SIGNATURE-----


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: code promotion / changeset deployment process - best practices?

[oleksa borodie <ol...@gmail.com>]

> I'd recommend this:
> 
> trunk
> branches
>    issues
>      issue(id)
>    maintenance
>      maint(id)
> tags
>    trunk(id)
>    maint(id)

 Could you give me the difference between 'issue' and 'maint' please.
I thought that developers work on the branch together and merge
changes to trunk.

 Is there any 'The best practice of' concurrent develepment with Subversion?

Thank you

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: code promotion / changeset deployment process - best practices?

[Tom Mornini <tm...@infomania.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 15, 2005, at 7:23 AM, ed.wittmann@fiserv.com wrote:

> if I have this model:
>
> trunk ->
> ------------ testing ->
> --------------------development ->
> ------------------------------------developer-branch1
> ------------------------------------developer-branch2
>
> And my process is given as thus:
>
> - developer-created branches can only be merged with the development
> branch;
> - 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
> trunk;

Branching is good, but too much branching is not gooder. :-)

I'd recommend this:

trunk
branches
   issues
     issue(id)
   maintenance
     maint(id)
tags
   trunk(id)
   maint(id)

Developers always work under branches/issues

Integration is done by merging from branches/issues/issue(id) to trunk
and/or branches/maintenance/maint(id) as appropriate.

Tags are made from trunk or branches/maintenance/maint(id) as 
appropriate.

Testing is promoted to from tags only, no need for branches.

Production is promoted to from tags only, no need for branches.

- -- 
- -- Tom Mornini
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFCNxgBzaKkuvKwKvcRApUvAJ4mUzV13S2D4ZhuYz3CoHHa0me5xACcCInQ
EAK0WQi7ZcwGOZUI41a0K60=
=3o+J
-----END PGP SIGNATURE-----


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org