headers
Jim Tilander | 1 Apr 2008 01:22

Re: [p4] Scripting P4win.

So what's it for, well. I'd like to track what each clientspec is
doing, what kind of operations they've done and basically go back in
time from the client's point of view. I guess I could do with just a
server command that would dump the whole clientspec state for me. I
basically don't want to roll out my own client, nor to "train" anyone
to do a custom sync option (that way lies endless support :)

As for p4win, the day that perforce stops distributing that piece of
software is the day I stop using perforce. It's the one redeeming UI
client, p4v is a sea of usability misunderstandings and confusion
(hey, I get confused in there, and I fancy myself somewhat familiar
with perforce, how can I expect a new user to have any chance?). I
can't make odds and ends of that thing, and it made the fatal try to
support multiple platforms within one (gui) toolkit. Cross platform
only means that it's equally crappy on each platform. No, give me a
native client, one that looks and feels like the platform I'm on.

Furthermore, it is my opinion that p4win should be officially supported.

/j

On Sun, Mar 30, 2008 at 5:42 AM, Robert Cowham <robert <at> vaccaperna.co.uk> wrote:
> Short answer is no.
>
>  Longer answer is:
>
>  - p4win is officially deprecated (currently minor updates only to work with
>  new server versions) and all new work is going into p4v
>
>  - no event hooks currently provided, custom tools (and some flexibility on
(Continue reading)

Permalink | Reply | 10 comments |
headers
Gabor Maghera | 1 Apr 2008 02:59
Picon
Gravatar

Re: [p4] Keeping everybody in sync with client specs?

I don't know if this is an option in your environment, but I would encourage
containerizing.  In other words, don't allow top level directory creation
(similar to what John Dix points out).   If people add a subdirectory to a
directory already covered in your client spec, chances are your build script
will not have to change (there are a few exceptions to this).  If they need
to add a new top-level directory, that is best handled via a request to the
depot curator (who is likely to be on the build team).

Cheers,
Gabor

On Sun, Mar 30, 2008 at 10:46 PM, Dix, John <JDix <at> medmanagesystems.com>
wrote:

> I have restricted top level branch access to builders only. Developers
> have read only access to our baseline branch, Dev branches are created by
> request only and permissions are assigned as needed. They are given full
> permissions to their "personal" branch.
>
> With regard to maintaining the branches and who does what, developers are
> 2nd class citizens and the builders are in charge. We're held to strict FDA
> standards with regard to auditing so to let developers do what they will
> would cause our company to fail and FDA audit.
>
> ________________________________
>
> From: perforce-user-bounces <at> perforce.com on behalf of Nittin chawala
> Sent: Sun 3/30/2008 10:03 PM
> To: Roy Smith; perforce-user <at> perforce.com Com
> Subject: Re: [p4] Keeping everybody in sync with client specs?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff A. Bowles | 1 Apr 2008 04:20
Picon
Favicon

Re: [p4] Scripting P4win.

I think that there might be a different way to get this information.

   1. The time/date/IP/everything (including command args) is written to
   the Perforce server log, if you've turned on the right debugging flags, and
   that should get you 90% of the information.
   2. If you also have a "spec depot", you can have versioning of your
   client workspace specs (and label specs) so that you can match things up, if
   you need.

[Aside: I admit that it'd be easier to track as a trigger, but that's not
available to you for all operations - only the ones that modify forms such
as "client workspace spec" and "job" and "changelist".]

When in doubt, ask the support folks. They've heard it all (I assure you)
and might have a good way to save you
a bit of time  for your project.

   -Jeff Bowles

(ps. Howdy do, Rick! Hope you're well.)

On Mon, Mar 31, 2008 at 4:22 PM, Jim Tilander <jim_perforce <at> tilander.org>
wrote:

> So what's it for, well. I'd like to track what each clientspec is
> doing, what kind of operations they've done and basically go back in
> time from the client's point of view. I guess I could do with just a
> server command that would dump the whole clientspec state for me. I
> basically don't want to roll out my own client, nor to "train" anyone
> to do a custom sync option (that way lies endless support :)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Lewis | 1 Apr 2008 07:15
Picon

[p4] Fwd: Keeping everybody in sync with client specs?

forgot to include the list...

---------- Forwarded message ----------
From: Dave Lewis <dlewis78731 <at> gmail.com>
Date: Tue, Apr 1, 2008 at 12:15 AM
Subject: Re: [p4] Keeping everybody in sync with client specs?
To: Roy Smith <smith_roy <at> emc.com>

Probably a more formal template methodology.  We check  our template
 clients into perforce.  This is not strictly needed anymore, but it
 does provide better tracking, and such.  The other thing we did was
 that we used the same template between builds and development.

 I would imagine that you should build your build client each night
 based on the current development template.  We built from scratch
 every night using a new client built from the currently checked in
 template client.  Each template client mapped its checked in template
 into itself.  This nails down the exact template to be used when you
 label a release.  (there were provisions in the script that generated
 the new nightly build client to use the template as of the
 changenumber the build was to be synced to)

 Also, checked in client specs can have comments in them.  When they
 are read into perforce, the comments are just filtered out as the
 client is defined.

 dave

 On Sun, Mar 30, 2008 at 3:07 PM, Roy Smith <smith_roy <at> emc.com> wrote:
 > We've got a recurring problem involving keeping everybody on the same
(Continue reading)

Permalink | Reply | 0 comments |
headers
Evgeny | 1 Apr 2008 11:16
Picon

[p4] Eclipse P4WSAD and AltRoot

Hello Perforce Users,

While trying to help a developer work with Eclipse both in Windows and in
Unix, I discovered that P4WSAD 2007.3 does not support AltRoot. Seems like
P4WSAD 2007.3 only looks at the "Root:" field, and when trying to open files
it tells me "this file is not managed by perforce", even though using the
command line it works perfectly.

Even though in the background it is clearly using the command line "p4"
client. And I was using the same client spec, netapp location, and AltRoot
.... for both windows and unix.

Is there anything I can do to remedy this and get it to work?
Any ideas?

Regards,

Evgeny
_______________________________________________
perforce-user mailing list  -  perforce-user <at> perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user
Permalink | Reply | 0 comments |
headers
Ivey, William | 1 Apr 2008 17:37
Picon
Favicon

Re: [p4] Scripting P4win.

I've never understood the emphasis on P4V myself. Since 97% of
my users interact with Perforce only from Windows, and the rest
use the command line or run scripts, the cross-platform aspect
is pretty useless to us. (Our products are heavily cross-platform,
not our developers.) A crisp, reliable GUI with native feel is
much more important in terms of the developer's experience.

Those who do use it (usually out of loyalty to all things Java
based :-) don't make use of any of its special abilities. (I
find the few things P4Win does better to be more useful, day to
day.)

I did like the admin tool, but it was buggy and I've gone back
to the command line for admin tasks. (I'll probably try it
again and see if the recent patches made it less frustrating.)

Just my experience and preference.

-Wm

-----Original Message-----
From: perforce-user-bounces <at> perforce.com
[mailto:perforce-user-bounces <at> perforce.com] On Behalf Of Jim Tilander

So what's it for, well. I'd like to track what each clientspec is
doing, what kind of operations they've done and basically go back in
time from the client's point of view. I guess I could do with just a
server command that would dump the whole clientspec state for me. I
basically don't want to roll out my own client, nor to "train" anyone
to do a custom sync option (that way lies endless support :)
(Continue reading)

Permalink | Reply | 6 comments |
headers
Amiri McCain | 1 Apr 2008 18:27
Favicon

Re: [p4] Scripting P4win.

Have you seen Subversion's Windows Explorer user interface?  I've got to
admit, it's pretty slick.  Users interact directly through the explorer
window and even the right click menus have icons. (google images >>
Subversion screenshots) 

I have found the Perforce Windows Explorer plug-in to be extremely slow
and painful and it does not give you folder level information the way
Subversion does. I put a request in for this feature.

I would prefer not to have to interact with another software package
(p4v, p4win, etc), but would prefer to do things directly in windows
explorer since I am familiar with the interface.

am

-----Original Message-----
From: perforce-user-bounces <at> perforce.com
[mailto:perforce-user-bounces <at> perforce.com] On Behalf Of Ivey, William
Sent: Tuesday, April 01, 2008 8:38 AM
To: perforce-user <at> perforce.com
Subject: Re: [p4] Scripting P4win.

I've never understood the emphasis on P4V myself. Since 97% of
my users interact with Perforce only from Windows, and the rest
use the command line or run scripts, the cross-platform aspect
is pretty useless to us. (Our products are heavily cross-platform,
not our developers.) A crisp, reliable GUI with native feel is
much more important in terms of the developer's experience.

Those who do use it (usually out of loyalty to all things Java
(Continue reading)

Permalink | Reply | 3 comments |
headers
Peter Weldon | 1 Apr 2008 20:07
Favicon

Re: [p4] P4V 2007.3 cannot log in to P4AUTH slave server?

On Fri, Mar 28, 2008 at 1:48 AM, Arthur van Dongen
<Arthur.van.Dongen <at> tsolve.com> wrote:
> Hello all,
>
>  I recently upgraded my client P4V to 2007.3/147477. Since then I can
>  still log in to the P4D server with the users configured, but *not* to
>  the P4D server which points to the first one using the P4AUTH config
>  option.  P4V reports "no such user", P4Win 2007.3 logs in OK. The P4V
>  release notes only mention fixing a bug in P4AUTH, a search in the P4D
>  release notes gives no results.
>
>  Both servers run on a single physical machine, version 2005.2/93627 on
>  Windows Server 2003, using AD integration. Behaviour stays the same
>  regardless whether I use a proxy.
>
>  So, does anyone else have this problem, and which server versions are
>  involved? Are there workarounds available? Will upgrading the server
>  solve the problem?

Yes I can confirm the same problem. Running P4V/NTX86/2007.3/149519
against P4D/NTX86/2005.2/104598 (2006/08/04) using P4AUTH results in
P4V  reporting "no such user" for most users. Testing with the
perforce sample depot  the existing user bruno works fine but any
newly created users give the "no such user" error. Newly created users
work fine from the command line.

The problem does not occur with P4D/NTX86/2006.2/136815 (2007/10/12)
or P4D/NTX86/2007.3/143793 (2008/01/21), I did not test any other
versions. I did not test any previous P4V versions.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Vance | 1 Apr 2008 22:26

Re: [p4] Scripting P4win.

FYI: P4V is not Java-based. The project to create the Java-based 
cross-platform UI was killed years ago because it didn't Perforce up to 
expectations. P4V is Qt-based.

Steve

Ivey, William wrote:
> I've never understood the emphasis on P4V myself. Since 97% of
> my users interact with Perforce only from Windows, and the rest
> use the command line or run scripts, the cross-platform aspect
> is pretty useless to us. (Our products are heavily cross-platform,
> not our developers.) A crisp, reliable GUI with native feel is
> much more important in terms of the developer's experience.
>
> Those who do use it (usually out of loyalty to all things Java
> based :-) don't make use of any of its special abilities. (I
> find the few things P4Win does better to be more useful, day to
> day.)
>
> I did like the admin tool, but it was buggy and I've gone back
> to the command line for admin tasks. (I'll probably try it
> again and see if the recent patches made it less frustrating.)
>
> Just my experience and preference.
>
> -Wm
>
>
> -----Original Message-----
> From: perforce-user-bounces <at> perforce.com
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ivey, William | 1 Apr 2008 22:43
Picon
Favicon

Re: [p4] Scripting P4win.

I did not realize that. I seem to remember java as a
prerequisite once upon a time, maybe for some ancillary
tool. (I've been installing it mostly to get the extra
tools for P4Win so I haven't paid much attention to it
other than to play with it from time to time.)

> because it didn't Perforce up to expectations.

Heh, I kind of like the phrase that typo created.
Perforce has given me higher expectations.

-Wm

-----Original Message-----
From: Stephen Vance [mailto:steve <at> vance.com] 
Sent: Tuesday, April 01, 2008 3:26 PM
To: Ivey, William
Cc: perforce-user <at> perforce.com
Subject: Re: [p4] Scripting P4win.

FYI: P4V is not Java-based. The project to create the Java-based 
cross-platform UI was killed years ago because it didn't Perforce up to 
expectations. P4V is Qt-based.

Steve

Ivey, William wrote:
> I've never understood the emphasis on P4V myself. Since 97% of
> my users interact with Perforce only from Windows, and the rest
> use the command line or run scripts, the cross-platform aspect
(Continue reading)

Permalink | Reply | 0 comments |

Gmane