Home/ Questions/Q 3323996
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T23:22:08+00:00

(I am a new perforce user, but have used lots of other source code

  • 0

(I am a new perforce user, but have used lots of other source code control systems in the past.)

We use a change list to check-in each bug fix; the change list comment includes the bug ID therefore it is easy to track when a bug fix has been checked into a branch.

However I can’t see an easy way to find all branches a given bug fix has been merged into, or to find all bug fixes that have been merged into a given branch.

As far as I can tell perforce does not track all the branches a change list have been merged into. As I understand it, when a merge is done in perforce the history is not copied into the target branch so the only history in the target in the comment on the change list the merge was done into.

What am I missing?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Perforce tracks where revisions of a file have been integrated, but it doesn’t automatically propagate check-in comments with your bug-tracking metadata.

    Given a changelist on a particular branch, you can tell whether Perforce thinks the changelist has been integrated by asking Perforce to integrate the changelist. (I’m using “branch” in the more traditional source-control sense, to mean a particular branch of the source code tree, rather than in the specific Perforce sense to mean the path of integration between these two source code trees.) Let’s say you’ve been working in //source/project/trunk/... and you have a changelist @1234 that you’d like to check whether it’s been integrated into your release branch //source/project/rel/.... Create a client that maps //source/project/rel/... and execute:

    $ p4 integrate -n //source/project/trunk/...@1234,1234 //source/project/rel/...

    If Perforce tells you “All revision(s) already integrated.”, changelist @1234 has been integrated, and that bugfix ought to be available on the release branch. If Perforce lists files that have changed, those files have not been integrated. (It’s also possible for some files in a changelist to be integrated and not others, which may make for some interesting problems.)

    This doesn’t scale especially well — you need to check each bugfix on each branch you care about, though it does lend itself to automation.

    You can use the “unsupported” Perforce command interchanges to get a quick idea of what changelists have not been integrated from one branch into another. (In Perforce parlance, “unsupported” means something like “might not work the same in the next revision, but we think it could be useful so we’ll release it anyway”.) To see what changelists haven’t been integrated from our example trunk to release branches, execute:

    $ p4 interchanges //source/project/trunk/... //source/project/rel/...
Change 1236 on 2010/10/10 by user@client 'Fixed some bug you don't care about'
Change 1235 on 2010/10/09 by user@other_client 'Fixed some other random bug'

    In this example, I haven’t listed changelist @1234 because it’s already been integrated into the release branch. One problem I’ve experienced using interchanges is it’ll list every newer revision after an unintegrated change, even if the newer revisions themselves have been integrated, so if you’re cherry-picking revisions for a release branch you may see changelists listed again. I use interchanges as a first pass to get a rough idea of what I need to integrate, then look at integrate to get a better idea of what’s really missing.

    (Perforce also supports a similar concept of “jobs”, that let one attach particular fixes to particular changelists, but my organization doesn’t use them so I don’t know how well they work or whether they are propagated automatically on integration.)

    • 0