[p4] obliterate and branching

[Craig James]

Just an update on this for those interested.

I've been in contact with the guys at perforce and we've resolved our
issue.

Given the integration command "p4 integ source dest", where source has
12 revisions, with a previous integration from revision 6 of the source
file...

In essence:

* I freed up space using obliterate on source, only leaving the head
revision (12)
* Attempting a normal integrate meant any record of the previous base
(6) no longer existed and it reported an error "... is missing from the
rev table"
* Overriding the integration command with "p4 integ source#head,#head
dest" still failed as the command in this case still needs at least two
revisions in the source file history
* We gave the source file a new base by just opening it for edit and
submitting
* The integrate command then worked (baseless merge with "p4 integ -I
source dest") as it now had a revision below the head in the source file
history.

So it follows the same suggestion that Stanton made - by rebasing the
source files - but we didn't have to delete/readd to do this, just open
for edit (so no space wasted - yay!)

My 'source' file also has the S1 option set on it (to just keep the
latest revision) but that did not affect this issue - as this option
purges files but leaves the file histories intact.

Our plans from now is to:
 1. Set +S1 on all our binary content.
 2. If we hit a problem in our next integrate, force a revision in the
file history by opening for edit/resubmitting

The guys from perforce want to follow it up a bit further - it is being
logged as a separate issue to the one Stanton indicated.
 
Regards,
Cj

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Craig James
Sent: Friday, 5 October 2007 3:02 PM
To: Stanton Stevens; perforce-user at perforce.com
Subject: Re: [p4] obliterate and branching

Ouch.  That's a lot of files for us too.

I'll log a support issue with perforce and see if there is any update
before I head down that route.

Thanks for passing on your experience.

Cj

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Stanton Stevens
Sent: Friday, 5 October 2007 2:21 AM
To: Craig James; perforce-user at perforce.com
Subject: Re: [p4] obliterate and branching

Hi Craig, 

I posted that warning because I had to go to a lot of trouble to fix the
problem when it happened to us. I have not heard from Perforce that they
have fixed the bug. You need to re-base the files. If I recall, we ended
up deleting the head rev of the source files (many thousands in this
case), re-adding, and then integrating with -f. That was probably
overkill, your best bet is to work with Perforce support. That will also
help remind them to fix this bug. 

Stanton 

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Craig James
Sent: Wednesday, October 03, 2007 5:32 PM
To: perforce-user at perforce.com
Subject: [p4] obliterate and branching

Hi there,

We're doing a project that involves a fair degree of branching and
integrations over code and large amounts of binary files (totalling
around 20GB in each intergrate).

To stop our perforce database space exploding I've been selectively
obliterating file versions in the binary content - as we are really only
interested in keeping the head revisions of many of those files (but
want to keep the lazy copies so we don't need the extra copy in
perforce).

Unfortunately we've just hit this bug noted in this Feb post
http://maillist.perforce.com/pipermail/perforce-user/2007-February/02094
0.html

Meaning that when we want to integrate a new file version it brings up
an error like this:
    Operation: user-resolve
    Operation 'user-resolve' failed.
    //FL07/Main/GCGame/Content/Debug/Debug.upk is missing from the rev
table!

Our server info is:
Server date: 2007/10/04 09:52:40 +1000 E. Australia Standard Time Server
version: P4D/NTX86/2007.2/131374 (2007/08/09)

Our current workaround is to open the file for edit in the branch, copy
over the new file and check it back in - but this adds a new copy of the
same file and exacerbates the space issues on the server.

My questions are:

* Has the bug mentioned in the post above been addressed yet / planned
soon?  

* Alternatively, is there another workaround that can effectively
disconnect a file from it's merge history - allowing a new integration
to proceed without error?


Regards,
Cj
_______________________________________________
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