Changelist as atomic units (was: [p4] Building without changelists)

Chuck Karish karish at well.com
Mon Oct 1 07:01:33 PDT 2001


At 08:16 AM 10/1/2001 +0200, Gilad Benjamini wrote:
>What I want do, is to use changelists as an atomic building block for
>many operations, such as synching, labeling, querying about labels.
>Perforce provides that ability, but in a very partial manner, and it is
>not built into the tool. e.g. a set of "chosen" changelists for a version
>might create a conflict, which Perforce is not aware of, as it was resolved
>in a later changelist (which is not include in my set)

Are you using the word "conflict" to mean something other than overlapping
changes on the two file versions that you're merging?  That's what the
conflicts are that 'p4 resolve' reports.  It doesn't look ahead to see what
might have been fixed later.

>>From a project-manager's point of view, this is an immensely strong
>tool. It practically mimics the way people think "I want to create a version
>based on 3.34 plus bug fix #997".

Why can't you do this?  The only issue I see is the one that's mentioned in the
branching FAQ, that the changes you don't merge are still listed as pending.
If you want to fix that you can do null integrations (resolved with '-ay').

>I realize that implementing this is by no means simple or straightforward.
>I do, however, believe that this is a direction Perforce should take.

I think there are two issues here: turning off the "integration pending" record
for changes you don't want in the child branch, and choosing the appropriate
base version for resolving integrations that have holes behind them.  In my
experience, doing null integrations to fill the hole solves both problems.


Chuck Karish            karish at well.com           (415) 317-0182




More information about the perforce-user mailing list