[p4] How do YOU identify the code set for a release?

[Shawn Hladky]

>>Perforce branching seems to require a physical copy on the
>>client disk of the whole source tree for the branch.
use the -v switch to prevent this.

>>the requirement to fill out a text-based form to make a
>>simple branch makes scripting the process an interesting exercise in
>>text file manipulation.
use P4Perl, P4Ruby, P4Python, P4.Net, P4COM, or one of the other APIs and
this is a piece of cake.

On Jan 3, 2008 6:07 PM, Steve Williams <stevewilliams at kromestudios.com>
wrote:

> I've been using Subversion for a few years now, using the branching
> method described below, and it has been working great.  I am in the
> process of being persuaded to shift to Perforce and I wish to use the
> same branching technique.  However, the difference between Subversion
> and Perforce in branching is hindering the shift.  Subversion's
> branching is cheap in both server disk space, client disk space and
> client time (a total of a few seconds to branch a multi-gigabyte source
> tree).  Perforce branching seems to require a physical copy on the
> client disk of the whole source tree for the branch.  When the source
> tree is tens of gigabytes and the physical copy of the source tree on
> the client disk takes half an hour or so, this method quickly falls out
> of favour, plus the requirement to fill out a text-based form to make a
> simple branch makes scripting the process an interesting exercise in
> text file manipulation.
>
> So, I'm also keen to see what the preferred and most efficient approach
> is, and if they are the same or mutually exclusive.  The branching
> approach makes sense to me, but it does not seem to fit within the
> Perforce methodology from what I have seen.  The Perforce docs even say
> that they based their branching model on the ancient method of making a
> physical copy.  I'd like something that is not a hark back to the 80's
> when source trees were measured in kilobytes.
>
> --
> Sly
>
>
> Rick Macdonald wrote:
> > I've been creating Perforce branches as you show in your option #3 for
> > almost 10 years now. I wouldn't give credit to Subversion or to me for
> > this idea. It was just a natural thing to do. I confess, I've never made
> > a label once in my life.
> >
> > A "physical" branch is simple, easy, cheap, very visible in the depot
> > (GUI) and on disk, with names that match, has a history that is easy to
> > see, etc. Being a branch, you're not limited to a single changelist
> > number if that doesn't fit the way you accumulate what goes into a
> > release. Using ideas from Laura's book, which includes Jobs, you can
> > script simple queries to show what fixes are in one release compared to
> > any other (perhaps helping to automatic release notes), and on and on.
> >
> > I'll be watching this thread to see if anybody thinks this is _not_ a
> > good way to go!
> >
> > ...RickM...
> >
> > Steve M. Robbins wrote:
> >
>  >> Option #3 is to use the subversion convention.  Recently, I've been
> >> using subversion for more and more of my open source hobby work.  So
> >> I've been exposed to the (standard?) subversion way of doing things
> >> which is basically to create a branch for each released version.  Thus
> >> there is a 1.x codestream branched from the main line, and then a
> >> 1.1.1 codestream branched from the 1.x stream.  A naming convention is
> >> used to distinguish the kinds of branches.  Subversion uses something
> >> like:
> >>
> >>     ..../project
> >>             /trunk     (main codestream)
> >>             /branches
> >>                 /1.x   (1.x codestream)
> >>                 /2.x   (2.x codestream)
> >>             /tags
> >>                 /1.1.1
> >>                 /1.2.0
> >>                 /2.2.1
> >>
> >> Stabilization, for example, will be carried out in .../branches/1.x,
> >> and then this is branched into ..../tags/1.1.1.  I believe that only
> >> convention prevents one from integrating into /tags/1.1.1 more than
> >> once.
> >>
> >> This scheme begins to appeal to me more since it is "filesystem-like"
> >> and thus the p4v browser gives you a way to browse revisions quite
> >> directly.
> >>
> >
>
>
>
> This message and its attachments may contain legally privileged or
> confidential information. This message is intended for the use of the
> individual or entity to which it is addressed. If you are not the addressee
> indicated in this message, or the employee or agent responsible for
> delivering the message to the intended recipient, you may not copy or
> deliver this message or its attachments to anyone. Rather, you should
> permanently delete this message and its attachments and kindly notify the
> sender by reply e-mail. Any content of this message and its attachments,
> which does not relate to the official business of the sending company must
> be taken not to have been sent or endorsed by the sending company or any of
> its related entities. No warranty is made that the e-mail or attachment(s)
> are free from computer virus or other defect.
>  _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>