Best Practices for Subversion Workflow

  • brockangelo

    (@brockangelo)


    14 years, 11 months ago

    I am new to subversion and writing plugins, and one thing I’ve noticed is that some developers use trunk as their stable release and others use tag numbers. It appears to be 6 and 1/2 dozen. But since I’m learning subversion, I’d like to think through best practice for my workflow. So my question:

    Do you think it is better to use trunk as your sandbox, or to use a new tag number as your sandbox?

    From what I’ve gathered so far, you can write plugins / work with svn in one of two ways:

    1. Edit your trunk code for testing, leaving the readme.txt file pointing to the latest stable tag until trunk is ready to go. Once trunk is ready, copy the contents of trunk to a new tag number and update your stable version in readme.txt in trunk to point to the new tag. Or,
    2. Leave the most current stable version of your code in trunk. Leave the readme.txt pointing to trunk as the latest stable tag. Do all of your testing inside a new tag version number folder. Once your new version is stable, copy all of your new version files to trunk.

    Seems like if you do it one way, you’ll branch to a new tag when you are starting to test a new feature; and in the other, you’ll have to merge a revision back to trunk after the feature is stable. Or something like that…svn has a lot of terms to learn: merge, branch, switch, update, commit – oh, and don’t forget “add”.

    I’m mainly curious about efficient workflow, but so far my experience with subversion has been the exact opposite of “efficient workflow”. 🙂

Viewing 1 replies (of 1 total)
  • rdmenotte

    (@rdmenotte)

    14 years ago

    Typically what I’ve seen and done in many other development environments, is when you are adding\removing a feature, fixing a bug, or anything like that, go ahead and put it in its own tag. Tags to me are like releases and trunk can be thought of as experimental; it may or may not work.

    Specifying Stable: <ver> in your readme will instruct WordPress to make that version the most obvious one to download. That way, you can do whatever you want to the trunk and no one should get mad (they’re supposed to use the stable one right?)

    Once you’ve made a handfull of changes and your version numbers have climbed and you’re ready to specify a new base level that you think everyone should be using, update the Stable tag in the readme and commit your changes.

Viewing 1 replies (of 1 total)
  • The topic ‘Best Practices for Subversion Workflow’ is closed to new replies.