4 ms·
It doesn’t seem very helpful with modern workflows.. Usually you don’t work on several separate projects, you work on one project and you switch branches depend
by tigershark 5y ago
It doesn’t seem very helpful with modern workflows..
Usually you don’t work on several separate projects, you work on one project and you switch branches depending on the feature that you are working on.
You can easily merge in your current branch the changes from another branch.
With the subprojects workflow how can you import the changes of another subproject considering that you are probably in the middle of the debugging or something else?
- galaxyLogic 5y agoSmalltalk-80 -like "sub desktop-projects" are for smaller scale changes than "feature branches". They are about implementing different parts of a "feature" when that requires changes into several sub-modules. I think "Mise-en-place" is really a good metaphor for it because you can arrange every tool-window you need for a given sub-task in a context dedicated solely for that sub-task. It is like in a kitchen you would have a separate "desktop" for preparing the meat and a separate one for creating the salad. They would need different tools around them, for easy access right? A good example is implementing a client-server feature. In the parent-task-desktop you are implementing client-side code that requests something from the server and then does something with the response it gets form the server. But the needed server-side function is missing, you must implement it too. Open a sub-project-desktop for working on that server feature. Open any editors and browsers and test-sets and change-lists and debuggers and spec-documents in that server sub-desktop. You can have similar windows in the parent client-desktop but those are totally separate from the windows you have opened in your sub-task-desktops. It is easy to switch between the two back and forth which is often needed because when you change something in the server-part you may need to make a corresponding change in the client-part as well. Or you discover a bug which is not about what you are working on now, but you realize it is best to fix it before doing anything else. Open a sub-project-desktop for fixing it. When you're done you get back to the exact same work-environment you were in when you discovered the bug and realized you better fix it right away.