[p4] [P4] Remaking a branch.

Justin nockmss at gmail.com
Thu Aug 20 16:32:10 PDT 2009


On Thu, Aug 20, 2009 at 11:48 PM, Matt Janulewicz <
matt.janulewicz at lucasfilm.com> wrote:

>  I think the pain of re-pointing client specs is far easier to get through
> than worrying about (and more than likely messing up) any subsequent merges
> to DEV.
>
> "The work done in DEV contains lots of changes but is no longer useful to
> us."
>
> Then for all intents and purposes, this is different code and should be
> called something else on a different branch. You're basically proposing a
> branch that has a certain history and purpose, then at some point in time
> switches to a useful set of code with a different purpose. Not good.
>

The purpose is actually the same. It's a branch for work done by our
'Internal' team who often do experimental changes We simply want to reset
and reconcile everything as both branches diverged too far from each other.
I don't want to pollute our depot with another branch every time we wish to
'reset' the branch! Both branches are virtually identical in structure,
except some SDKs we use have incremented a few versions.


It seems like your intuition is telling you that this is not the right way
> to go. Listen to it. Oooooooommmmmmmm. Be Zen and create a new DEV branch
> that is named something more descriptive. :)
>

DEV was just an example name, however our actual branch name of 'Internal'
isn't that much more descriptive... :) but it works for us and I'd rather we
not change it if possible.


When you move on to upper-management and all your current developers have
> been promoted, the new crew will thank you for not making a weird, hybrid
> branch of mixed-purpose. You have to think about the future as well as the
> past.
>
> Oooooooooommmmmmmmmmmm.


I disagree that I'm attempting to make a mixed-purpose branch, but I could
well be wrong there... but IMO that's derailing the discussion from my main
interest, i.e. Can a branch be reset? And so far nobody has given any
inclination of 'yes'. I've got a big feeling I'll be persuading my
colleagues to create a fresh branch tomorrow morning...


Your thoughts have been much appreciated, thanks!


Justin




-Matt


Justin wrote:

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><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><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