0

I'm not sure if trunk-based development is strictly the right term here, but let me outline the process.

Say I have some code like:

//utils.js
function someFunction(foo, bar) {
   //implementation 
}


//main.js
main() {
     someFunction("foo", "bar"); 
}

And I've picked up a task to:

Replace someFunction with someOtherFunction that accepts a single a 'biz' parameter'.

Now, I've given a very small piece of code here, but lets say that actually that new function involves creating some other functions etc, and also I'm going to be replacing it in multiple places.

Now one way I might do this, is to do a 'big shebang' PR and just do all of the work in a single PR:

//utils.js
-function someFunction(foo, bar) {
-   // implementation
-}
+function someOtherFunction(biz) {
+   // implmentation 
+}


//main.js
main() {
-     someFunction("foo", "bar"); 
+     someOtherFunction("biz"); 
}

The problem with this is that these commits can end up being very big (a recent one affected 200 files), which makes the PR process cumbersome.

Instead, I could structure my work so that I submit several small PRs:

  1. Create the new function
+function someOtherFunction(biz) {
+   // implmentation 
+}
  1. Convert the callers over the using the new function
main() {
-     someFunction("foo", "bar"); 
+     someOtherFunction("biz"); 
}
  1. Remove the old function
-function someFunction(foo, bar) {
-   // implementation
-}

The problem I'm having with this approach is the way that these PRs end up looking, at least on Bitbucket.

PR1 is fine.

But until PR1 is merged, then PR2, if PR2 is pointed at trunk, contains the diff of both PR1 and PR2.

And again on PR3.

This means that until PR1, and then PR2, then I still have the same 'large diff' issues on my PRs.

You might just say that 'The problem is that PR1 isn't being merged quick enough', which is fair enough. But one thing still to point out is that there isn't a way of communicating that PR2 depends on PR1, unless you're explicitly commenting as such. That is - how do I communicate to someone that PR2 shouldn't only be reviewed as a diff between PR2 and PR1?

The other problem you can have is that say you get some feedback on PR1, 'it shouldn't be called someOtherFunction call it someBizFunction'. I make that change, but then then I need pull that change in to PR2 and PR3.

Any suggestions for thinking about this kind of problem?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.