Announcement

Collapse
No announcement yet.

Is it okay to use such kind of scheme..?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Is it okay to use such kind of scheme..?

    Hello.

    Currently we've nor branches, nor tags in our team. The more contributors come,
    the more conflicts we have. I'd like to share my draft with convensions in SVN.

    REPOSITORY LAYOUT

    Repository Root:
    svn+ssh://example.com

    Trees:
    /trunk
    /branches
    /branches/stable
    /tags

    /trunk should be always usable. Commit quick fixes and small changes there.
    Merge alpha-tested branches into it.

    /branches is place for long-term work, or things large enough to annoy other team
    members.

    /branches/stable is a special branch checked out on all servers. Don't ever
    commit here directly. Merge with the latest tag(/tags) intead.

    /tags is a place for snapshots(releases). Once /trunk is ready to update working
    servers, we create a tag, merge into /branches/stable and fetch the changes with
    `svn update' on each machine.


    RELEASE NAMES


    A release is a tag like /tags/x.y.z, where
    x is major version
    y is minor version meaning new feature(s) added
    z is a patch number meaning bug fixes


    RELEASE CYCLE

    Let's assume we already have /tag/3.0.0 merged into /branches/stable on all
    servers, and /trunk has no difference with /branches/stable.

    Once we need to submit a patch, we commit it to /trunk, create /tag/3.0.1 and
    merge it into /branches/stable.

    When we need a new feature, we create a branch, say, /branches/feature-upload
    (as a copy of /trunk, of course). Small bug fixes and small changes in /trunk
    still have place. Therefore, to keep /branches/feature-upload in sync, we
    peroidically merge /trunk into it:

    Code:
    $ pwd
    /var/www/s3-branch-feature-upload
    $ svn merge svn+ssh://example.com/trunk
    Obviously, the more frequently it synced, the less likely we run in conflicts.

    When the branch is done, well-tested, and ready to be merged back with the main
    development line, the trunk, we do the following:

    Code:
    $ pwd
    /var/www/s3-trunk
     
    $ svn update
    $ svn merge --reintegrate \
    svn+ssh://example.com/branches/feature-upload
    # Don't forget --reintegrate option at this step!
     
    # ...
    # Test it thoroughly!
    # ...
     
    $ svn commit -m "Merge with feagure-upload branch into trunk"
     
    # Create a tag
    $ svn copy svn+ssh://example.com/trunk \
    svn+ssh://example.com/tags/3.1.0 \
    -m "Add: upload feature"
     
    # Merge the tag into the stable branch
    $ cd /var/www/s3-stable
    $ svn update
    $ svn merge --reintegrate \
    svn+ssh://example.com/tags/3.1.0
     
    # Delete the branch (if no further work needed)
    $ svn delete \
    svn+ssh://example.com/branches/feature-upload \
    -m "Delete feature-upload branch, since it is already merged into trunk"
    So is it okay to work this way? Isn't it complicated?

    Regards.
    Last edited by r.osmanov; 12-22-2011, 03:24 PM.

  • #2
    Sounds like a normal workflow, with the exception of your "stable branch". A branch implies changes will occur and eventually be merged (or deleted, if it's an experimental set of changes that don't pan out). I would recommend instead having a tag named "stable" which is just a symlink to the appropriate tag. Then when you declare a tag "stable" you just re-point the symlink to the right place - no merging, no conflicts.

    Comment


    • #3
      Originally posted by andyl View Post
      Sounds like a normal workflow, with the exception of your "stable branch". A branch implies changes will occur and eventually be merged (or deleted, if it's an experimental set of changes that don't pan out). I would recommend instead having a tag named "stable" which is just a symlink to the appropriate tag. Then when you declare a tag "stable" you just re-point the symlink to the right place - no merging, no conflicts.
      Thank you.

      I thought one shouldn't ever commit to tags when decided to make /branches/stable. Indeed, it'd be prettier to have such a tag instead.

      Comment


      • #4
        Originally posted by r.osmanov View Post
        Thank you.

        I thought one shouldn't ever commit to tags when decided to make /branches/stable. Indeed, it'd be prettier to have such a tag instead.
        You have to commit to /tags to create a tag. The convention is to not change a tag once it's been created.

        Nothing wrong with a symlink in /tags which is points to the "right" tag to use all the time.

        Comment


        • #5
          Originally posted by andyl View Post
          You have to commit to /tags to create a tag. The convention is to not change a tag once it's been created.

          Nothing wrong with a symlink in /tags which is points to the "right" tag to use all the time.
          Sure, I've got it. Thanks again.

          Comment

          Working...
          X