[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: "freezing" a tag or branch tree

From: <marcin.slusarczyk_at_pl.abb.com>
Date: 2004-05-27 16:28:05 CEST


Daneil, could you show me your pre-commit file?
I do not know how to get what command is being executed and do not know
how to recognize that it is copy from branches or trunk. svnlook does not
give me such data.

Marcin Slusarczyk

Daniel wrote:
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.
Received on Fri May 28 17:30:24 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.