[p4] re-base a branch
Andrew May
acmay at acmay.homeip.net
Fri Dec 30 09:27:05 PST 2005
On Thu, 2005-12-29 at 15:06 -0800, Knut Forkalsrud wrote:
--- Andrew May, Thu, 29 Dec 2005 09:00:22 -0800 ---
>
> > It is not that they are not interested in stabilizing, but rather
> > their time frame for stable is later than the demo work.
>
> If you are going to need //newhw's code/help to get //demo1 ready on
> time, it is going to affect the //newhw team anyway. That's why they
> may want to split their work between a "stable" branch and an
> "experimental" branch. If you can get by fine on your own then don't
> bother. Just cherry pick the individual changes you want from the
> //newhw branch.
I am not sure we do need //newhw's help anymore from its current point.
We (//demo) were just lucky that they (//newhw) are at a point were the
things we need from them are a working/unit tested part of the complete
system. They need to be able to continue to add in many other seperate
features as well during the same timeframe as the demo, but I don't
think any of it will be helpful for us.
In fact they actually checked in a change last friday that hurt me a bit
too. Last week someone else went through the task of building and
verifing that the //newhw build worked as they said it would.
And this week I naively did just a p4 integrate //newhw/... //demo/...
to dry run the big merge step without a check-in, before I noticed the
friday checkin. But I spare the details here.
The point of the branch is so we don't impact the //newhw team directly.
And forcing them to do an experimental branch would not help.
> Given the flow of change, all changes in //main should be propagated
> continuously to //newhw. I'm sure there have been good reasons why
> that hasn't always happened. Don't forget that these are guidelines
I am sure too :>
>only, not hard rules. Add a generous dose of pragmatism. Perforce
> will support you much more than most other revision control tools.
Yes perforce does provide many options. And that is really what I am
looking for here. The best way is a very code/timeline specific choice.
I am not even sure what all my real options are. I need to see the
actual commands sequences (or something close) for myself to understand
the reality of the ascii art since the picture does not exist in
perforce itself in any form other that at the individual file level.
I did layout the 2 ways I could do things in the other email.
It did not even occur to me to do another branchspec before I got the
responces here, I was just thinking of changing the first on instead.
A minor thing that could be fixed after the fact, but one of those small
details that is just missing from all the pictures.
If there are any other variants on what I could do I would appriate it.
Thanks.
More information about the perforce-user
mailing list