For me the roadblock for multiple iterations through merging of the different parts (S, C, then C+S) is the time that will be spent on rebuilding the mainline. That's why I would like to have C+S in the same source tree then run tests for S, tests for C (if they can be run standalone) and C+S tests, then tests for whatever other pieces may be affected. (As I mentioned, there are more layers than client + server in my situation, e.g. client + transport + server). I am not really try to ignite the holy war between Perforce and Git (and why would one???), but if you are interested in the answer on how you'd do your scenario in Perforce, it would be: "use shelved changelists". In Perforce, you could "shelve" the changelist, similar to "stash" in Git, but the difference is that the Perforce shelved changes are accessible across clients. I.e. the other developer can "unshelve" these pending changes to its sandbox (to the same or the different branch) so that sandbox would get the pending changes as well. That would be like the developer made these changes himself. Whatever automated/manual process is involved, it is typical to run "a trial build/tests" on shelved changelist (i.e. uncommitted yet files) to verify the quality of changes. Git achieves the same through the ease of manipulation with branches and I like the way it does it much more. My question was about how to robustly handle "multiple pending commits" which in Perforce are represented by concept of pending changelists. On Thu, Jul 13, 2017 at 2:22 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Stefan Beller <sbeller@xxxxxxxxxx> writes: > >> On Tue, Jul 11, 2017 at 8:45 AM, Nikolay Shustov >> >>> With Git I cannot seem to finding the possibility to figure out how to >>> achieve the same result. And the problem is that putting change sets >>> on different Git branches (or workdirs, or whatever Git offers that >>> makes the changes to be NOT in the same source tree) is not a viable >>> option from me as I would have to re-build code as I re-integrate the >>> changes between the branches (or whatever changes separation Git >>> feature is used). >> >> you would merge the branches and then run the tests/integration. Yes that >> seems cumbersome. > > Sometimes the need to make trial merge for testing cannot be avoided > and having branches for separate topics is the only sensible > approach, at least in the Git world. > > Imagine your project has two components that are interrelated, say, > the server and the client, that have to work well with each other. > In addition, you want to make sure your updated server works well > with existing clients, and vice versa. > > One way that naturally maps this scenario to the development > workflow is to have a server-update topic and a client-update topic > branches, and separate changes to update each side with their own > commits: > > s---s---S server-update topic > / > ---o---o----o----M mainline > \ > c---c---C client-update topic > > And during the development of these *-update topics, you try three > merges: > > (1) Merge S to the mainline M and test the whole thing, to make sure > that existing client will still be able to talk with the > updated server. > > (2) Merge C to the mainline M and test the whole thing, to make > sure that updated clients will still be able to talk with the > existing server. > > (3) Merge both S and C to the mainline M and test the whole thing, > to make sure the updated ones talk to each other. > > If there is no significant development going on on the mainline in > the meantime, (1) and (2) can be done by trying out S and C alone > without making a trial merge with M. The same for (3)---it can be > just a trial merge between S and C without updates that happened on > the mainline. > > I'd love to hear from folks in Perforce or other world how they > address this scenario with their system.
