Jump to content
JanReimer

List of Changesets not merged from one branch to another

Recommended Posts

Hi,

we are looking for a way to list all changesets of a certain branch that have not been integrated into another branch.

Our szenario is a beta deployment branch. There are a lot of changes directly made on that branch that are meant to be integrated into /main again. Other changes should not be integrated (workarounds etc.). We created a branch from /main that is used for this integration. The changes that have to be integrated are cherry picked from the beta deployment branch. We want to have a list of all changesets that are not merged in any way (merge or cp) from the beta deployment into the integration branch.

I looked into the cm find examples on your homepage. I can detect branches that are not completely merged in terms of having changesets after the last regular merge. This does not fit in our scenario.

Best regards

Jan

  • Like 1

Share this post


Link to post
Share on other sites

Nobody out there who might have a solution?

I just found the branch properties which helps us a bit. However, I don't understand the difference between "Merge from" and "Rebase from"; it seems that merge type "Merge" is always a "Rebase from" which makes sense. But there are also cherry picks that are of type "Rebase from" which I don't understand.

Best regards

Jan

Share this post


Link to post
Share on other sites

Hi Jan,

so for example, for the attached picture, you would like to know what's is missing to be merged into main, right?

Well, you basically need to re-implement part of the merge tracking algorithm... first get all the merge links:

>cm find merges where srcbranch='main/scm002' --format="{srcbranch}@{srcchangeset} --> {dstbranch}@{dstchangeset}({type})" --nototal
br:/main/scm002@15 --> br:/main@16(merge)
br:/main/scm002@18 --> br:/main@21(cherrypick)
br:/main/scm002@19 --> br:/main@22(merge)
br:/main/scm002@20 --> br:/main@23(cherrypick)

Then the list of changesets in the branch:

C:\Users\manu\wkspaces\testing-p4file>cm find changeset where branch='main/scm002'  --nototal
1155     15       /main/scm002         11/3/2016 10:19:19 AM mlucio   testing
1167     17       /main/scm002         11/3/2016 10:19:43 AM mlucio   testing
1173     18       /main/scm002         11/3/2016 10:19:53 AM mlucio   testing
1177     19       /main/scm002         11/3/2016 10:20:03 AM mlucio   testing
1181     20       /main/scm002         11/3/2016 10:20:08 AM mlucio   testing

15, 17, 18, 19 and 20 are candidates as pending to be merged, let's start discarding candidates.

15 is having a merge link -> Already merged.

17 is NOT having a merge link -> Candidate.

18 is having a cherrypick -> Merged.

19 is having a merge link -> That means all previous changesets can be set as merged too, 15, 17, 18 and 19. 17 is not a candidate anymore.

20 is having a cherripick -> Merged.

So we end up without candidates.

Notice you have to keep track of interval cherrypicks and also subtractive merges.

Hop it helps!

brexpmerges.PNG

Share this post


Link to post
Share on other sites

Hi Manu,

your post describes perfectly our situation. Starting from you example I think it is feasible to script this algorithm. I was hoping that someone already has solved this or that Plastic SCM has a feature to simply show the desired information.

We already used this workaround: Merge from cs20 to cs23, see what the merge engine would like to merge. By this we know which content has not been merged, yet. However, we still don't see the list of changesets involved in that merge. Maybe the GUI client could provide that kind of information?

Best regards
Jan

Share this post


Link to post
Share on other sites

Hi Jan,

I was going to propose you the workaround you have just mentioned, I didn't do it because although you can know if there are pending merges you can't know the changeset where the candidates are coming from. CLI and GUI are missing this info.

I'm not aware of customers having the algorithm implemented, it shouldn't be hard but if you have questions I'll be happy to help. And of course if you end up scripting the algorithm it would be nice if you could publish it, maybe we can write a small blog post about it.

Share this post


Link to post
Share on other sites

Hi,

I think I'm looking at a situation similar to JanReimer. I am looking for tooling that helps me answer "which changes have been done to the project between the previous release and the current one?"

 

In our case, things work like this:

* We do most development on task branches. People merge results back to main at the end of each task. Sometimes people do development directly on the main branch.

* We create a new child branch for each release. A couple of merges, a couple of cherry-picks from main to the release branch - then we are done. Occasionally, a fix gets re-implemented on the release branch, when it is too difficult to cherry-pick it (this is most common with binary data changes).

All in all, the simplest way for us to identify a release is to talk about its changeset ID. This will typically refer to the last changeset ID on the release branch. Sometimes we might decide to release a build made off another changeset on the release branch (because the last change was bad in some way).

 

Now, the question I think would like to ask of the Plastic client is:

Quote

Given <changeset ID A> and <changeset ID B>, what is the difference? I.e. which changesets are part of the history leading up to <changeset ID B> but not part of the history leading up to <changeset ID A>?

 

I do not care about the few changes which are in <changeset ID A>'s history but not in <changeset ID B>'s history.

 

I think one way to solve this would be to algorithmically start from <changeset ID A> and flatten the graph; follow merge/cherrypicks recursively. Then do the same, from <changeset ID B>. This will produce two lists of changesets. I can then remove all entries in <list B> which also appear in <list A>. Subtractive merges/cherrypicks complicate things a bit, haven't thought much about that yet.

 

I think another way would be to find the last full merge that leads from /main to <changeset ID A>. Then work backward from <changeset ID B>, collect changesets, until that particular merge is encountered.  Special cases required for cherrypicks etc afterward.

 

So, er. What's the status on something like this? Do I need to build my own tooling for it? Does something exist already?

Share this post


Link to post
Share on other sites

This yields a list of the individual files that are different between the two changesets:

Quote

cm diff cs:<changeset ID A> cs:<changeset ID B> --format="{path} {revid}"

However, going backwards from there to the changesets involved is cumbersome and I'm not sure this is a viable approach.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×