[p4] [P4] Remaking a branch.

Justin nockmss at gmail.com
Thu Aug 20 16:51:47 PDT 2009


On Fri, Aug 21, 2009 at 12:18 AM, Peter Buckley <buckmeisterq at gmail.com>wrote:

> When you say you're looking for a way to "re-make branches without
> obliterating," that is antithetical to the notion of source control in
> general and perforce specifically. Once you make something (a branch, a
> file) in source control, it is preserved forever, unless you obliterate. The
> fact that perforce would warn and need the -d flag when people add a
> previously deleted file in the case of File5 is how the tool is designed to
> work, and it is a desired behavior in most cases.


I agree.



> It would be exceptionally trivial to use //DEV1/... and just automate the
> update of the left side of everyone's clientspecs - for most users they're
> only going to care about their local disk coming down as c:/dev.


I agree too.



>
> If you're set on doing this against your own better sense, I would say you
> probably shouldn't have deleted //DEV/... - that will probably be the source
> of more "haunting" than if you had just done an integration from
> //MAIN->//DEV and called that changelist the cutoff.


Yes. I think the main issue stems from the fact that you can't
ignore-integrate adds/deletes. If it were possible then it'd be plain
sailing, but there's probably some fundamental reason why it's not feasible.
Typically you'd alter the branchspec to do so but that doesn't apply in this
case.

Even if I didn't do the initial delete of DEV, and just integrated MAIN->DEV
as you suggest, I expect there'd still be just as many unresolved changes
waiting to stop integrations going smoothly.


Thanks for the info. I'm leaning much more towards making a new branch as we
go along... it's certainly the choice that helps one sleep better at night
:)



Justin



>
>
> Thanks,
> Peter
>
> -----Original Message-----
> From: Justin <nockmss at gmail.com>
>
> Date: Thu, 20 Aug 2009 23:04:01
> To: <dlewis78731 at gmail.com>
> Cc: <perforce-user at perforce.com>
> Subject: Re: [p4] [P4] Remaking a branch.
>
>
> That was one of my first thoughts too :)
>
> However, we'd like to keep using DEV; it's simpler for the end-users
> (nothing's changed on their POV), we don't have to repoint clientspecs,
> revision history is preserved in a natural way, etc etc.
>
> My hope is that some sort of recipe exists for remaking branches. If it's
> not possible, then that's just as interesting... :)
>
>
> Cheers,
>
>
> Justin
>
>
>
> On Thu, Aug 20, 2009 at 10:41 PM, Dave Lewis <dlewis78731 at gmail.com>
> wrote:
>
> > just create a "DEV2" branch, then no issues whatsoever!
> >
> >
> > On Thu, Aug 20, 2009 at 12:02 PM, Justin<nockmss at gmail.com> wrote:
> > > Hi there, I have a question regarding "remaking" an existing branch and
> > hope
> > > to get some help.
> > >
> > >
> > > Let's say I have two branches, where DEV is originally branched from
> > MAIN.
> > > //depot/MAIN/...
> > > //depot/DEV/...
> > >
> > > The work done in DEV contains lots of changes but is no longer useful
> to
> > us.
> > > Basically we want to start DEV all over again as a fresh branch from
> > MAIN,
> > > but without obliterating DEV.
> > > So far, I've deleted DEV by executing 'p4 delete //depot/DEV/...'. Was
> > that
> > > a mistake? What should I do next? I'm thinking of integrating MAIN->DEV
> > > next.
> > >
> > > My main question, is whether there's scope for unresolved changes
> > existing
> > > in MAIN or DEV which will haunt future integrations between the
> branches,
> > > silently causing problems down the road. Am I being too paranoid there?
> > >
> > > Thanks,
> > >
> > >
> > > Justin
> > > _______________________________________________
> > > perforce-user mailing list  -  perforce-user at perforce.com
> > > http://maillist.perforce.com/mailman/listinfo/perforce-user
> > >
> >
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>



More information about the perforce-user mailing list