JanReimer Posted September 30, 2016 Report Share Posted September 30, 2016 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 Link to comment Share on other sites More sharing options...
JanReimer Posted November 3, 2016 Author Report Share Posted November 3, 2016 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 Link to comment Share on other sites More sharing options...
manu Posted November 3, 2016 Report Share Posted November 3, 2016 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! Link to comment Share on other sites More sharing options...
JanReimer Posted November 3, 2016 Author Report Share Posted November 3, 2016 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 Link to comment Share on other sites More sharing options...
manu Posted November 3, 2016 Report Share Posted November 3, 2016 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. Link to comment Share on other sites More sharing options...
Mikael Kalms Posted September 18, 2018 Report Share Posted September 18, 2018 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? Link to comment Share on other sites More sharing options...
Mikael Kalms Posted September 18, 2018 Report Share Posted September 18, 2018 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. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.