Interest

[schultze]

I've been making some changes for personal use and am wondering if
they are of any interest to the group:

1. Config: Set a list of paths that exclude activity on files in the
path.
2. Config: Set a path (maybe this also ought to be a list of paths) to
which NiftyPerforce is restricted (i.e., ignore all files outside the
path)
3. Queuing: If a P4 operation fails (the assumption is that failure is
only if P4 is not installed or cannot connect), leave the item in the
queue. Change processing of the queue to loop until queue is empty or
cmd returns failure.
4. Auto change eligible file (based on exclude/include path config) to
writeable status to eliminate the IDE prompt for (Edit In Memory, Make
Writeable, Cancel).

The motiviation for all of these changes was to deal with using the
IDE on a) solutions not under Perforce, b) while P4 server is
unavailable (as in a temporary VPN connection scenario). I can see
that the move to executing the P4 commands on a separate thread also
addresses the same issues.

Regards,
Tim Schultze

[Jim Tilander]

That's interesting, I've heard from another source that people use
plugins like this for offline operations and queue them up. Would said
queue operations be simply triggered by the first failure, or do you
have to flip some switch? I personally don't use this mode, I've much
more prefered just making everything writeable and then use
p4offlinesync.py instead to simply gather up the changes. Of course
that also means that I can not have offline diffs etc ...

This concept also funnily is related to what I've been doing latley,
p4sync, which backs up live changelists and restores them afterwards.
It would be really handy if this thing produced archives like that....

As for the exclusion thing, what do you use this for? Could you give
an example, I'm curious.

The auto "read only flag remove" is already in the plugin, have you
found it not to work?

/j

--
Beware of architect astronauts.

[schultze]

For queuing, I simply use a .Peek call to get the item and only
call .Dequeue if the cmd.Run returns success (this is a little
assumptive, I know). So, queuing is just a natural result of your
existing approach.

The reason we want exclusions is because we love the auto-add so much
but have code generators that are part of our build process as well as
using Web services. In both of these cases, the build actually
produces code modules that are become part of our project. Since that
code is on par with object modules (as far as source code control is
concerned), we don't want them auto-added to Perforce. So, we make
sure those files go in distinct paths and put those paths on the
exclude list.

I'm not sure about the auto "read only flag remove" capability (I
didn't see it in the code). In the official 1.2 version, if I'm not
connected to Perforce, the IDE "freezes" for about 20 seconds and then
(I think) the IDE's "Edit in memory, make writeable" popup appears. In
the current code trunk, the background request is started and
immediately the IDE puts up its "Edit in memory, make writeable"
popup. I tried putting a loop/sleep in there (after putting the cmd in
the queue) and even though the sleep doesn't seem to actually allow
interaction with the thread, it did appear to give the thread enough
time to let Perforce do the read-only attribute flip (maybe it is
Nifty doing it, though). The loop/sleep had to do about 500 or 600
milliseconds of delay to keep the IDE's popup from coming up.

On Feb 2, 4:34 pm, "Jim Tilander" <j...@tilander.org> wrote:
> That's interesting, I've heard from another source that people use
> plugins like this for offline operations and queue them up. Would said
> queue operations be simply triggered by the first failure, or do you
> have to flip some switch? I personally don't use this mode, I've much
> more prefered just making everything writeable and then use
> p4offlinesync.py instead to simply gather up the changes. Of course
> that also means that I can not have offline diffs etc ...
>
> This concept also funnily is related to what I've been doing latley,
> p4sync, which backs up live changelists and restores them afterwards.
> It would be really handy if this thing produced archives like that....
>
> As for the exclusion thing, what do you use this for? Could you give
> an example, I'm curious.
>
> The auto "read only flag remove" is already in the plugin, have you
> found it not to work?
>
> /j
>

> On Feb 1, 2008 9:22 AM, schultze <timschul...@gmail.com> wrote:
>
>
>
>
>
>
>
> > I've been making some changes for personal use and am wondering if
> > they are of any interest to the group:
>
> > 1. Config: Set a list of paths that exclude activity on files in the
> > path.
> > 2. Config: Set a path (maybe this also ought to be a list of paths) to
> > which NiftyPerforce is restricted (i.e., ignore all files outside the
> > path)
> > 3. Queuing: If a P4 operation fails (the assumption is that failure is
> > only if P4 is not installed or cannot connect), leave the item in the
> > queue. Change processing of the queue to loop until queue is empty or
> > cmd returns failure.
> > 4. Auto change eligible file (based on exclude/include path config) to
> > writeable status to eliminate the IDE prompt for (Edit In Memory, Make
> > Writeable, Cancel).
>
> > The motiviation for all of these changes was to deal with using the
> > IDE on a) solutions not under Perforce, b) while P4 server is
> > unavailable (as in a temporary VPN connection scenario). I can see
> > that the move to executing the P4 commands on a separate thread also
> > addresses the same issues.
>
> > Regards,
> > Tim Schultze
>
> --

> Beware of architect astronauts.- Hide quoted text -
>
> - Show quoted text -