[p4] Checking out with intention to not submit

Olle Hallin olle.hallin at hit.se
Mon Aug 2 02:58:36 PDT 2010

I don't agree that this is a narrow use case. We see it frequently here at
our shop, mostly for configuration files.

We have adopted a change list naming convention ("DO NOT SUBMIT"), but IMO
it would be nice if
Perforce was aware of the underlying semantics.

I see at least the following situations where p4d should behave differently
for open-for-modify files:
* When deleting a user
* When opening a file opened-for-modify by someone else (suppress merge
* When doing "p4 opened -a //depot/some-path/..." (Which we do before
starting release builds in order to detect unsubmitted work-in-progress)

Olle Hallin
Senior Java Developer and Architect
olle.hallin at crisp.se

2010/7/25 Paul Du Bois <paul.dubois at gmail.com>

> On Fri, Jul 23, 2010 at 11:24 AM, Grills, Jeff N
> <Jeff.N.Grills at disney.com> wrote:
> > As I've mentioned in other follow-ups, my current work-around is to flush
> the file to #0, and then chmod/attrib it.  P4 will complain every time I
> sync about not being able to clobber the writable file, so I will get
> regular reminders that I've messed with the client's content without p4d's
> knowledge.
> I think this is not a good idea for a feature. It adds a concept with
> a large surface area to address a  narrow use case.
> That said, since (as far as I know) the only people who need to do
> this are p4 administrators at disney, another possible solution for
> them is to create a new "sandbox" user and "p4 -u sandbox edit" the
> files. Perforce will then hold you to your promise not to submit those
> files. The rest is as Jeff Bowles suggests (don't use +l, do use
> communication)
> p
> _______________________________________________
> 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