[p4] Branch deprecation procedure?

Gabor Maghera gmaghera at gmail.com
Wed Sep 19 09:35:22 PDT 2007


You could also use inclusionary mapping to render the branch deprecated.
Create a group which has no members and assign a p4 protect entry such that
the deprecated branch is accessible only by the newly created group.  This
gives you the benefit of easily giving someone access to the dead branch
later if needed, by adding them to the group.

Gabor

On 9/19/07, Robert Cowham <robert at vaccaperna.co.uk> wrote:
>
> > Now as far as the material on the branch itself, I see these
> > options ahead of me:
> > 1) Do nothing -- leave the branch there.
> > 2) Add an entry to the protections table to mark it read-only
> > 3) Delete (p4 delete) the branch
> >
> > I don't like #1 because it leaves a folder around that over
> > time, will add to the noise of obsoleted branch folders when
> > browsing the depot.
>
> I always recommend that you do something simple like insert a year
> component
> in the pathname, e.g.
>
> Instead of:
>
>         //depot/Product/SOME_DEV_BRANCH/...
>
> You do:
>
>         //depot/Product/2007/SOME_DEV_BRANCH/...
>
> (using Laura's naming convention of uppercase branchnames - though I do
> find
> things like a suffix .br work very well too, and don't lead to confusion
> with acronyms etc).
>
> This convention for development type branches, of which you may end up
> having many over the years, means it is obvious when something is a couple
> of years old and unlikely to be of interest.
>
> It can also work with release type branches - depends on how many you are
> going to have.
>
> The key thing here is that I want to avoid clicking at one level in the
> GUI
> and having potentially hundreds of items (e.g. branches) at that level.
> Over
> time this becomes very messy, and does impact performance.
>
> > Option #2 sounds interesting as it will essentially hide it,
> > but I worry about doing this for every branch that ends up
> > deprecated -- if the protections table grows large, it can
> > negatively impact performance.
>
> Covered by others.
>
> > Option #3 sounds somewhat drastic, but still recoverable.
>
> Again this can still cause problems if there are hundreds of things at
> that
> level, as depending on the GUI options to view deleted files or not will
> depend on what you can see.
>
> Robert
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>


More information about the perforce-user mailing list