Re: "freezing" a tag or branch tree

On Thu, 2003-09-18 at 06:51, james-tigris@jrv.org wrote:
> The specific scenario we're thinking of is someone in Sustaining
> Engineering checking out a tag to reproduce a failure in the field,
> fixing the bug and committing the fix without remembering to switch
> to the right branch first.

  We have this scenario too, and we solve it this way:

    1) No commits can occur in /tags, other than a copy
       from /trunk or /branches. We manage this with a
       pre-commit hook that is the same across all repositories
       (i.e. it never changes, other than the initial setup, there
       is no server admin involved).

    2) If someone wants to update a tag, they *have* to copy it
       to /branches (and name it appropriately), make their change,
       fix it, and then move the branch back to /tags. Tags
       can't be deleted or overwritten.

  This gives us:

    1) No-body futzes with tags. Tags should be an immutable record of
       "what it was like at the time", changing tags is Evil.

    2) Full change history on all files, you can trace "which tag was
       the parent of this one" kind of thing.

  We've also considered implementing a pre-commit script that enforces
  tags and branch names. I.e. a tag created by copying /trunk must
  be of the form "X_0_0", one copied from /branches must bump the last
  part of the tagname by one digit (we enforce a 3 digit version number
  scheme) and must have the same first portion of the version number as
  it's parent.

daniel

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Sep 18 00:41:12 2003