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

[Rick Macdonald]

Shawn beat me to it, but my reply would be the same. With -v I think 
you'll find the branch time similar to Subversion's. One thing to add:

The latest version of Perforce (p4d & p4) add a "-d" argument to the "p4 
submit" command line. If you know that no other files are mixed up in 
the default changelist for the clientspec making the release branch, you 
can just execute:

p4 submit -d "Creating branch for release $relNumber"

and avoid the fancy scripting for the submit form. Even so, you'll 
likely eventually write a little submit function in your favorite 
scripting language to do a submit when you can't use "-d" and can reuse 
it after that.

...RickM...

Shawn Hladky wrote:
>>> 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
>>
>>     
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
>