best practice? moving parts in/out of components?
We have the following use case:
Context: Experimental work, 100's of Eclipse projects (grouped into ~10 components). At any particular time, some of the Eclipse projects are "in use" and others are not. The ones that are not we keep in a standby component. For the next experimental run, we might want to swap out some existing Eclipse projects, and bring in some from the standby component. The way we currently do this is to use "move in repository" to move Eclipse projects around. Is this the best practice, or is there a better approach for this use case? Some alternatives, with pros/cons: Don't have a standby component; don't move in components. Instead use some kind of "configuration" to skip Eclipse projects not wanted. The problem with this is that when people "load" the repository workspace, they will be loading (potentially) a lot of not-needed projects, slowing things down, and bloating their Eclipse workspaces. These (unused) projects will also clutter up the package explorer, etc. The option of loading some subset is impractical when using the Eclipse client - the pick list would have 100's of projects, and you'd have to carefully find and deselect / select the right subset - an error-prone operation. (and every developer would need to do the same thing). Another alternative: same as above (don't have a standby component, etc.), but get the stream to have just the projects you want (for this run) by creating and delivering to the stream a change-set that removes the (currently) unused Eclipse projects. This seems a tedious operation. If done using the Eclipse client - you have to load all the unwanted projects together with the wanted ones, and then delete the unwanted ones, and then checkin and deliver. Furthermore, when you (in the next iteration) want to put back some subset of those projects, it's not clear how to easily do this. I suppose if you individually delivered each project deletion, you could search for that and reverse it. But if you deleted a bunch of projects under one change set, then you could do something clumsy like reverse that, then load those projects (they're not auto-loaded), then delete the ones you don't want among that set. None of these approaches seems very good, so I'm hoping to learn a better one for this use case :D . -Marshall Schor |
2 answers
You could try multiple streams. If experiment X adds a few projects, create a new stream for it using the same components as the main stream. When you want to do an experimental run, load the experiment's stream. You'll have to keep it in sync with any changes from the main stream though but the experiment will be isolated from polluting the main stream.
When the experiment is ready for release, you can deliver those changes from the experimental stream to the main stream. If you have no need for the experimental stream anymore, you can delete it. With this approach, it's easier to isolate the experimental changes. You'll still have to reload the stream but your developers won't have to think about which projects to load and which ones to delete. The basic concept though is to create a side stream (similar to branching with other versioning systems). It's ok to have a lot of streams configured for specific experiments. |
|
Thanks. Your suggestion I think is an augmentation of "alternative 2", except you suggest duplicating the stream and adding/removing things, and keeping the extra streams around as long as they are useful.
-Marshall Schor You could try multiple streams. If experiment X adds a few projects, create a new stream for it using the same components as the main stream. When you want to do an experimental run, load the experiment's stream. You'll have to keep it in sync with any changes from the main stream though but the experiment will be isolated from polluting the main stream. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.