On Wed, 2005-12-28 at 19:59 -0500, Stephen Vance wrote:
> Remember, things like "don't drive through hedges" are guidelines,
> not rules. In particular, there are a lot of normally desirable SCM
> behaviors that can reasonably go out the window when you are
> prototyping. One way to view branching is as a means to minimize
I am just trying to make sure that is ok to break the guideline without
too many consequences in the future.
We also have a funny history of prototypes being used very quickly for
a baseline.
> risk. Ask yourself whether there is any risk introduced by
> integrating from newhw to demo1. Are there any other scenarios that
> minimize this risk in better and useful ways? For example, do you
> think that you'll need to finish the demo on the current hardware
> target at any point in the future? If so, branching into demo1 limits
> that ability. Is there any benefit gained by creating a demo1-newhw
> branch? If you get yet another set of hardware thrown at you, will it
> be better to base it on the current state of demo1 or whatever state
> the ongoing development is in based on newhw?
I actually don't think there is too much risk in the changes to be made.
I see more risk in doing the merge and fixing the conflicts.
And the risk that all the demo work dies on the branch without getting
moved back to main.
> I suspect, reading between the lines, that branching newhw into demo1
I am not sure what you mean by this since they are both branches
already. How do you branch into a branch? Do you mean just merge newhw
into demo1? Maybe some p4 command examples, would be specific.
> is the right thing for your situation. You're skipping over a hedge
> for conventional development scenarios, but you are not in a
> conventional scenario.
I am just trying to foresee the consequences of doing this. The
conference presentation does not really seem to capture this well for
me. Maybe the practical perforce book goes into more detail, but I don't
have it yet.
I am still hoping to be in a conventional scenario someday.
_______________________________________________
perforce-user mailing list - perforce-user@xxxxxxxxxxxx
http://maillist.perforce.com/mailman/listinfo/perforce-user
|
