[p4] Changelist number in versions

Wed Dec 19 09:19:47 PST 2007

I rather be re-educated than not educated :)

In this case, I think I understand the choices but I don't want to have to
keep track (separately) of which changelist is the REAL change list for
every release. I also don't want the overhead of "locking" each release
branch. Thus, I originally wanted just one changelist. But now 2 will be
the limit and both would be able to recreate the build if we need to. I
will use the change list description to make sure that if someone
accidentally adds to the release branch after the release. we would still
know the correct changelist to rebuild.

I don't want to have to look in release notes or whatever in order to know
what changelist to use.

I think I've got a plan. I really don't think it is limiting or bad in a
way or even different than most people's suggestions. Just a couple of
detail are specific to our history and known processes.

Thanks for the help.

Todd 

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Robert Cowham
Sent: Wednesday, December 19, 2007 11:42 AM
To: perforce-user at perforce.com
Subject: Re: [p4] Changelist number in versions

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