[p4] [P4] Remaking a branch.

Justin nockmss at gmail.com
Thu Aug 20 18:07:13 PDT 2009


p4 duplicate is interesting, but wouldn't keep file history intact. However,
keeping history intact is the very thing causing a reintegration over the
deleted DEV to be fragile! Looks like I can't have it both ways. Thanks for
mentioning p4 dupe, sounds potentially useful :)

All I wanted was to know if you can 'remake' a branch without obliterating
it first, but it looks like it makes no sense to do so. I guess, to remake a
branch *is* to obliterate it!


Now all I have to do is convince my colleagues that "Hey... we can't use
that DEV branch anymore... we gotta make a new one." :)  That'll be fun.


Thanks for the info,


Justin


On Fri, Aug 21, 2009 at 1:02 AM, Gabor Maghera <gmaghera at gmail.com> wrote:

> It's possible to do so, but it can be a fragile and error-prone if you just
> reintegrate from main (since you will not want to propagate the deletion of
> the branch to main, but you may want to propagate other subsequent file
> deletions).  I agree with those who have advised you against it.
>
> If you are really keen on getting a new branch with a name previously used,
> you could use the p4 duplicate command (which is unsupported, btw) to
> replicate the previously used "DEV" branch (into something like DEV_1), then
> obliterate DEV, and finally branch DEV from main again.
>
> Really you would be doing the same thing which has been recommended in this
> thread over and over (use a different branch for a new project), but instead
> of giving a new name to a new branch, you would be giving a new name to an
> old branch, so your developers can access a new branch by the old name.
>
> I am not recommending you do this, but you've asked for a recipe, so there
> you go.
>
> Cheers,
> Gabor
>
> On Thu, Aug 20, 2009 at 4:32 PM, Justin <nockmss at gmail.com> wrote:
>
>> 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
>> _______________________________________________
>> 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