SVN, branches, and convention for migration/releases

Jun 13, 2009 at 7:20 PM

John et. al.,

This weekend, I'd like to reconcile the code I've updated to the Codeplex repository (and then start making regular updates from here onwards).  I just sync'd the server to my PC so now I have a working connection with SmartSVN.  As I was walking through the sync wizard, SmartSVN balked at not seeing a "Trunk/tag/branch" structure (whatever that looks like - I'm not one for over-engineered process, just mystified) and that reminded me that the DEV/MAIN branches seem to have some specific meaning for you, John.

I'd like to honour the pattern that John is working from, for two reasons: (a) if he's setup any branching structure, there's probably good reason to continue to use it (and I'll defer to experience anytime I don't have a strong feeling one way or another), and (b) any significant changes to the pattern are likely to make it that much harder for John to provide what help he's got time to contribute.

So, John:

  1. Is your approach to make all new code changes to the DEV branch, then have them tested out, and then copy those changes later to the MAIN branch?  Do you ever make any changes directly to the MAIN branch, or do you try to confine new check-ins to DEV and only *migrate* changes from DEV to MAIN?  Do you only build releases from MAIN?
  2. What is your usual decision criteria for "when it's time to migrate code from DEV to MAIN"?  Is it just a "length of time" measure?  Do you have specific tests that you run (manual or automated) that verify for yourself the code in DEV is ready to make part of MAIN?  Or is there some other step that you take?

Thanks, and I'll make sure to follow the pattern however it happens to work for you (and if I have a strong feeling on doing things another way, I'll obviously bring it to the dev team here first before implementing any changes.  No need to confuse the unpaid volunteers here... :))

Jun 15, 2009 at 4:38 AM
The DEV/MAIN branch scheme (also DEV/MAIN/PRODUCTION) are
recommendations from Microsoft. I choose them for no other reason than
that. It isn't that I particularly trust Microsoft's advice, but since
they wrote TFS I figured I would try it their way first.

> Is your approach to make all new code changes to the DEV branch, then have
> them tested out, and then copy those changes later to the MAIN branch?

Yes.

> Do
> you ever make any changes directly to the MAIN branch, or do you try to
> confine new check-ins to DEV and only *migrate* changes from DEV to MAIN?

No changes should ever be made to MAIN directly.

> Do you only build releases from MAIN?

Yes. Stuff that gets built from DEV should only get sent to private individuals.

> What is your usual decision criteria for "when it's time to migrate code
> from DEV to MAIN"?

When there is enough stuff for someone to bother writing the release notes.

> Is it just a "length of time" measure? Do you have
> specific tests that you run (manual or automated) that verify for yourself
> the code in DEV is ready to make part of MAIN? Or is there some other step
> that you take?

Sadly no. When I refer to the "test harness", that's just the console
application that we use for development testing and quick sainity
checks.

I would like to use formal unit tests, but I'm not doing it at this
time for three reasons.

1. Time.
2. Concern over how often they can run before hitting the daily limits.
3. Concern over the changing nature of the data we receive.

Once someone is able to overcome #1, I'm sure numbers 2 and 3 won't
present any long-term problems.

Jonathan

On Sat, Jun 13, 2009 at 11:20 AM, MikeSL<notifications@codeplex.com> wrote:
> From: MikeSL
>
> John et. al.,
>
> This weekend, I'd like to reconcile the code I've updated to the Codeplex
> repository (and then start making regular updates from here onwards).  I
> just sync'd the server to my PC so now I have a working connection with
> SmartSVN.  As I was walking through the sync wizard, SmartSVN balked at not
> seeing a "Trunk/tag/branch" structure (whatever that looks like - I'm not
> one for over-engineered process, just mystified) and that reminded me that
> the DEV/MAIN branches seem to have some specific meaning for you, John.
>
> I'd like to honour the pattern that John is working from, for two reasons:
> (a) if he's setup any branching structure, there's probably good reason to
> continue to use it (and I'll defer to experience anytime I don't have a
> strong feeling one way or another), and (b) any significant changes to the
> pattern are likely to make it that much harder for John to provide what help
> he's got time to contribute.
>
> So, John:
>
> Is your approach to make all new code changes to the DEV branch, then have
> them tested out, and then copy those changes later to the MAIN branch?  Do
> you ever make any changes directly to the MAIN branch, or do you try to
> confine new check-ins to DEV and only *migrate* changes from DEV to MAIN?
> Do you only build releases from MAIN?
> What is your usual decision criteria for "when it's time to migrate code
> from DEV to MAIN"?  Is it just a "length of time" measure?  Do you have
> specific tests that you run (manual or automated) that verify for yourself
> the code in DEV is ready to make part of MAIN?  Or is there some other step
> that you take?
>
> Thanks, and I'll make sure to follow the pattern however it happens to work
> for you (and if I have a strong feeling on doing things another way, I'll
> obviously bring it to the dev team here first before implementing any
> changes.  No need to confuse the unpaid volunteers here... :))
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email
> ([email removed])
>
> To start a new discussion for this project, email
> [email removed]
>
> You are receiving this email because you subscribed to this discussion on
> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any posts
> to this discussion will also be available online at codeplex.com