[p4] perforce vs. subversion

[Jeff Grills]

You can always write a perforce trigger that will forbid the submission of a
changelist which contains files you know should never be submitted.  I know
some places where any attempt to submit a changelist containing a file named
*.log will be refused (with a decent error message reported to the user as
well).  In this specific case, you could write a trigger that matches any
files containing /target/ and fail the submit.  Another thing that may be
feasible (though I've never tried) is to unmap those files from your
perforce client with an exclusionary mapping - that should prevent you from
even adding those files to a changelist, but the error message that perforce
will generate is probably not as clear to end users as you'd like.

j

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Knut Forkalsrud
Sent: Wednesday, May 03, 2006 12:28 PM
To: Sam Roberts
Cc: perforce-user at perforce.com
Subject: Re: [p4] perforce vs. subversion

My experience is that resynchronizing with the "tech note 2" approach
happens all the time.  A real problem is that users often add compiled
files.  We do a lot of Java and the build tool (Maven) creates a
"target" subdirectory for the compiled code.  There is a concept for
.p4ignore files in the spirit of .cvsignore, but it seems to be
special to the Perforce plugin for Websphere Studio (P4WSAD) and
something called p4delta (http://p4delta.sourceforge.net/)

Is there a generic way to manage this both for Windows and Linux
users?

Thanks in advance,

-Knut

PS: I know that compiled code should be kept away from the source
tree, but with maven that breaks down, the source directory is a
subdirectory of what's under revision control.