[p4] Is there an argument for deleting old releases?

Jay Glanville Jay.Glanville at naturalconvergence.com
Tue May 15 07:49:01 PDT 2007


Thanks for the suggestion James.

The "retire by making read-only" is what we're currently doing
(preventing people from accidentally submitting changes where they
wouldn't have any effect).  It always gives me 'warm fuzzies' when I
find out others got to the same decision as others.  ;-)

JDG

---
Jay Dickon Glanville



> -----Original Message-----
> From: James Prolizo [mailto:jprolizo at nexidia.com] 
> Sent: May 15, 2007 10:38 AM
> To: Jay Glanville; Perforce Users Mailing List
> Subject: RE: [p4] Is there an argument for deleting old releases?
> 
> 
> The option I have instituted here at my company is to "retire" the old
> codelines by changing the protections on the branches so that they are
> read only.  I then have given advice to the developers as to how to
> change their client spec to not get those folders if they don't want
> them anymore.
> 
> I do not think there is harm in deleting them as you can 
> always go back
> to a particular changelist to get the files or as you say show deleted
> files.  
> 
> I just like the idea of "retiring" codelines because then I can
> eliminate the chance of a checkin to that codeline.
> 
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Jay Glanville
> Sent: Tuesday, May 15, 2007 9:10 AM
> To: Perforce Users Mailing List
> Subject: [p4] Is there an argument for deleting old releases?
> 
> This is an opinion question, so I'm sure I'm going to get 
> many different
> answers! ;-)
> 
> In our P4 depot, we have a product with multiple releases, 
> structured in
> a somewhat 'standard' directory structure:
>   .../application/branches/rel_01.00
>                           /rel_01.01
>                           /rel_02.00
>                           /rel_02.01
>                           /mainline
> Along with the directory structure, we've labeled every major 
> milestone
> within each release.
> 
> Some of these releases are no longer in the field, and are therefore
> considered 'obsolete'.  Eg: all releases prior to 2.0 are no longer of
> interest.
> 
> The thought I had the other day was to delete (not obliterate) all
> obsolete branches.  Why?  To help differentiate all active and
> non-active branches (the active ones are the ones that you see by
> default).  In other words, to help reduce the amount of 
> 'visible noise'
> when a developer looks at the depot.
> 
> I can't think of there being any 'harm' with doing this, for if a
> developer needs to look at historical information, they can 
> still browse
> the old code by either using the milestone labels or by 
> 'showing deleted
> depot files'.
> 
> So, is there an argument for doing this?  Is there a good argument for
> NOT doing this?  What do you think?
> 
> JDG
> ---
> Jay Dickon Glanville
> 
> _______________________________________________
> 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