[p4] obliterate and branching

Craig James Craig.James at thq.com
Thu Oct 4 21:57:43 PDT 2007


Hi Robert,

I've just tried out this flag to no avail - it may have helped if we'd
used it from the start (we weren't on 2007.2 at that point but we'll
certainly use this flag in future new projects).

Think I'll have to resort to the more manual approach suggested by
Stanton.

Cj

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

It sounds like you could use the type S filetype with the n modifier.
That will undo lazy copies when it removes the repository file and will
create actual copies when branched. That would solve your space problem
and the obliterate might work as the file history remains. 
I'd be interested in hearing of anyone's experience with branching and
integrating type s files as we have a similar space problem and are
considering using +Sn as we move to 2007.2.

Rob McKenna

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



More information about the perforce-user mailing list