[p4] Changelist number in versions

[Robert Cowham]

Got rejected by Spam when sent direct so replying via the list... 

Todd, I have a suspicion you might not be fully clear as to how changelists
are a "built in" label for a known configuration (as well as a changelist
being an entitiy that contains a set of files) - so at the risk of teaching
my grandmother to such eggs:

If we have branched 100 files into //depot/rel1/... Using changelist @123

Then check in 3 more files in changelist @130.

The spec //depot/rel1/... at 130 means all files in that area upto and
including changelist 130. Thus it contains all the files in changelist 130,
and for any file not in that changelist, it contains the version in
changelist 123.

Does that help?

> -----Original Message-----
> From: Robert Cowham [mailto:robert at vaccaperna.co.uk] 
> Sent: 19 December 2007 16:28
> To: todd.benham at kodak.com
> Subject: RE: [p4] Changelist number in versions
> 
> To me it doesn't matter how many changelists are on the 
> (release) branch, the key thing is which changelist number 
> corresponds to precisely what I released.
> 
> Thus if //depot/rel1/... Has 4 changelists, @400, 500, 600, 
> 700, and yet only 600 is embedded in the release executable, 
> then I can ignore 700 (or at least treat it as something 
> after the release, perhaps a hotfix).
> 
> Does that make sense?
> 
> In normal case I would assume only a couple of changelists on 
> a release branch, but I don't particularly care as long as I 
> know which one.
> 
> Robert
> 
> > -----Original Message-----
> > From: todd.benham at kodak.com [mailto:todd.benham at kodak.com]
> > Sent: 19 December 2007 14:01
> > To: robert at vaccaperna.co.uk
> > Subject: RE: [p4] Changelist number in versions
> > 
> > I am not positive which part you are saying "I wouldn't recommend 
> > that" -- I think my "revised plan" is exactly what you said. No?
> > 
> > Why one changlist? Well, it is equal to having only one label. If 
> > there are multiple change lists, there is uncertainty and then it 
> > needs to be tracked elsewhere. I don't really want to track it else 
> > where. But two is workable. I just assume we will always 
> have exactly 
> > 2 change lists for a proper release.
> > 
> > >From previous posts, I came to the conclusion of using 
> branching and
> > changeslists are slightly better than labels even though labels are 
> > easier to use in most cases. I keep second guessing myself on that. 
> > BUT, there is really no good way to lock a branch (at least not a 
> > simple way that I know of). So, it seems one changelist is 
> best, but 
> > two are workable.
> > 
> > 
> > Todd
> > 
> > 
> > -----Original Message-----
> > From: Robert Cowham [mailto:robert at vaccaperna.co.uk]
> > Sent: Tuesday, December 18, 2007 5:59 PM
> > To: Todd D. Benham
> > Subject: RE: [p4] Changelist number in versions
> > 
> > 
> > > My conclusion is that what I *really* want to do is impossible 
> > > unless we were willing prevent check-in's on the server 
> during the 
> > > "critical"
> > > section of the process. Apparently, I confused some of you -- in 
> > > step 1), I meant "p4 integrate" into a new directory ...
> > > so there won't be a change list number using "p4 changes" 
> > > until step 5).
> > 
> > I wouldn't recommend that - I would do the integrate and 
> submit. Then 
> > do extra stuff and submit a separate changelist. It seems 
> like you are 
> > trying hard for a single changelist with branched files *and* some 
> > extra stuff - I am curiouse as to why?
> > 
> > > So my revised plan is to use $Change$ keyword expansion 
> (and/or the
> > > P4Python) for getting the number into the version.h file.
> > > Then p4 add it in the same changelist as the branch and 
> submit. Then 
> > > build from change list number (in case it changed), then submit a 
> > > separate changelist with "built"
> > > items. I have some details to iron out but the idea is in place.
> > > 
> > > Several of you suggested that I need not bother adding 
> version.h to 
> > > the release since it is generated and I understand that 
> idea. But we 
> > > have certain habits that make checking in the file kind of useful.
> > > 
> > > Todd
> 
>