Stefan Beller [off-list ref] writes:
On Tue, Jul 11, 2017 at 8:45 AM, Nikolay Shustov
quoted
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.
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 [off-list ref] wrote:
Stefan Beller [off-list ref] writes:
quoted
On Tue, Jul 11, 2017 at 8:45 AM, Nikolay Shustov
quoted
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.