[p4] Checking out with intention to not submit

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
notice)
* 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
www.crisp.se
http://www.linkedin.com/in/ollehallin
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>