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

[Steve Williams]

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.