Announcement

Collapse
No announcement yet.

SVN managing tags...

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

  • SVN managing tags...

    Hi,
    Is there an easy way of taking a tag of a proyect by name, modify it and re-commited.

    Scenarios:

    1.- A client reports a bug of an old version of my proyect (1.1) and i'm on versión 5.0.
    This client hasn't any support, so i want to take the tag "myProyect_version1.1", fix the bug, commited without messing up the
    current development of version 5.0 and send 1.1 fixed version to the client.

    2.- I have release a new version of my proyect (2.0) and send it to a client.
    A day later there is an urgent bug to fix, and i want to take the tag copy; fix it, and send it again to the client without messing with the
    current development of my proyect (post version 2.0).


    How would be the best approuch for this scenarios?


    Thank you very mutch.

  • #2
    Tags are copies - there's nothing special about them except their name. By convention, you don't modify tags, ever.

    For scenario 1, I would create a branch of your project at the revision where 1.1 was tagged & released, make your changes, tag that as 1.1.1 and release to the client. Alternately, you could tell them "you're 4 major releases behind, I no longer support anything more than 2 major releases back, please upgrade and then we can talk." Supporting extremely old releases is expensive - is it worth it?

    For scenario 2, same thing. Branch at the 2.0 release, make your fixes,tag & release. Make sure that you merge your changes (not copy, merge) into the main line of development too.

    Comment


    • #3
      Thank you very mutch for your replay, it help me to understand better svn branching usage.


      Originally posted by andyl View Post
      Tags are copies - there's nothing special about them except their name. By convention, you don't modify tags, ever.

      For scenario 1, I would create a branch of your project at the revision where 1.1 was tagged & released, make your changes, tag that as 1.1.1 and release to the client. Alternately, you could tell them "you're 4 major releases behind, I no longer support anything more than 2 major releases back, please upgrade and then we can talk." Supporting extremely old releases is expensive - is it worth it?

      For scenario 2, same thing. Branch at the 2.0 release, make your fixes,tag & release. Make sure that you merge your changes (not copy, merge) into the main line of development too.

      Comment

      Working...
      X