9 messages in com.perforce.perforce-user[p4] automatically building in the la...| From | Sent On | Attachments |
|---|---|---|
| Leo Zelevinsky | 23 Mar 2005 13:58 | |
| Matthew Janulewicz | 23 Mar 2005 16:51 | |
| Paul Andrei | 23 Mar 2005 17:21 | |
| jab | 23 Mar 2005 17:23 | |
| Douglas Palmer | 23 Mar 2005 17:52 | |
| Jason Williams | 23 Mar 2005 19:03 | |
| Grills, Jeff | 23 Mar 2005 19:13 | |
| Leo Zelevinsky | 23 Mar 2005 19:16 | |
| Nick Barnes | 24 Mar 2005 03:07 |
| Subject: | [p4] automatically building in the latest changelist number for abuild |
|---|---|
| From: | Jason Williams (str...@narus.com) |
| Date: | 03/23/2005 07:03:21 PM |
| List: | com.perforce.perforce-user |
Matthew Janulewicz wrote:
My two cents. I've had a lot of pennies today.
I hate writing answers that don't actually answer the question, and this one may open up a more philisophical question, but in my opinion, knowing the latest changelist is ultimately not as useful as it sounds.
If you (or anyone) is doing any kind of branching or merging, the latest changelist submitted (at a particular time) doesn't necessarily indicate what level the code is at.
Using the changelist number is meaningless in terms of determining the level the code is at. But that's not the useful part of using changelists in a version number. It becomes useful when you need to be able to recreate the existing build or debug it in any way.
Depending on how your code is structured, the latest changelist can tell you exactly how to reproduce what's been created. A label can tell you the same information, but a label doesn't necessarily tell you any more about the level the code is at either. It all depends on how you use the label.
In our case, our output is tagged with a label that determines what level the code is at (alpha, beta, etc.).
We've had situations where a lot of code was checked in, but suddenly marketing decided they only want these two specific changes in the next product.
If this happens early in the product lifecycle, this shouldn't be an issue since the "level the code is at" should also be somewhat related to the stage of the product lifecycle.
If marketing chooses to change the product late in the product lifecycle, you'll have bigger quality issues than what label the code is at.
If your marketing department never changes it's mind, and if your engineers only check in perfect code, in the order it is needed, then using merely a changelist number to identify code might be a good idea. But in a non-perfect world (which all worlds eventually become) you won't be able to stick to that policy/philosophy.
Why not? If you use the changelist merely as a way of reproducing a given build and not confuse it with the level the code may be at, it sounds like there's no problem.
Personally, I'd rather have a plan to accomodate it before it happens so I
don't end up
with two different software identification methods.
Won't you need two methods anyway? There's the marketing department and how they choose to identify the software (through version numbers, etc.) And then there's the engineering department that may have its own way of identifying builds. In this case, the changelist/label/branch information becomes engineering's mechanism.
As far as I know (willing to be schooled in this if I'm off the mark) a change list alone is not a sure-fire way to figure out what was in a build at any time.
That depends on how you work. At the moment, we resync an entire tree at a given changelist number. So a changelist IS a sure-fire way of figuring out what was in a build in our case.
The useful function I see in a label is the label name can determine the level of code. But the label name isn't necessarily useful in recreating a given build. It's the label contents that do that.
--Jason