[p4] [P4] Remaking a branch.

Justin nockmss at gmail.com
Thu Aug 20 14:58:09 PDT 2009


On Thu, Aug 20, 2009 at 10:26 PM, Paul-Marc Bougharios <
paulmarc.bougharios at gmail.com> wrote:

> Hi Justin,
>
> I think that after deleting the whole branch, the only "haunting" issue you
> might encounter is with future integrations.
>

Yes, future integrations are inevitable and are my primary concern. I want
users to integrate between MAIN+DEV just like any other branch, and not have
to keep in mind that it's not a 'fresh' branch.



>
> But I don't think your codeline will have any "past" changes, affecting
> your current branch.
>

It depends. Most of the files in MAIN and DEV will be reconciled because
they have a partner on the other branch. It's best if I use a concrete
example:

1. First: MAIN contains File1, File2, File3, File4. DEV contains File2,
File3, File4, File5.
2. I execute 'p4 delete //depot/DEV/...'.
3. Then: MAIN contains File1, File2, File3, File4. DEV contains nothing.
4. I execute 'p4 integ //depot/MAIN/... //depot/DEV/...' (including the
flags for baseless merge and allow re-adds... I think)
5. Then: MAIN contains File1, File2, File3, File4. DEV contains File1,
File2, File3, File4.

At this point, Files2, Files3, File4 are reconciled with no possibility of
getting haunted (I think!) which is great.
But what if someone does 'p4 add //depot/DEV/File5', and tries to integrate
that into MAIN? They'll end up with an (unexpected) warning saying it's a
re-add right? This is not the behaviour of a fresh branch and is exactly the
type of thing I would like to avoid.



> The issue with integration is that first, to re-integrate the branch, you
> have to bypass the delete revision [integrate -d].
>

Yep. I'll be 'accepting theirs', so it's a copy-integrate.



>
> Then, in subsequent integration, you will be needing the (-d) argument to
> delete obsolete files, and re-add "undeleted" ones.
>

Sorry, I'm not sure what you mean by this. From my understanding, subsequent
integrations over the initial re-integrate should pose no issues. Unless
you're talking about the unresolved files, such as File5 in my above
example.



> The only problem I see here is the need to always integrate around delete
> revisions.
>
> May I ask why you wouldn't consider obliterating the branch?
>

Although we don't need the old branch for working code, it still contains
valuable change information that we'd like to keep. It also preserves the
"If it was checked into Perforce, it's safe' feature.

Moreover, even if I do go for an obliterate, I am still interested in the
feasibility from a theoretical point of view.


>
> Cheers,
> Paul-Marc Bougharios
>


Sorry if what I've said hasn't been clear or is incorrect, I find
integration can be such a messy subject sometimes. :)

Thanks :)


>
>
>
> On Thu, Aug 20, 2009 at 8: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
>>
>
>



More information about the perforce-user mailing list