[p4] Workspace option: exclusive open

[Jeff A. Bowles]

I think Greg's pointing in the right direction. Better still, it's
something you can pursue now, not in a future release.

I would go a slightly more formal route: make a small script that does
an edit-lock-look sort of sequence:
    "p4 sync" the filename passed as an argument, to guarantee you are
up-to-date.
    "p4 edit" the file.
    "p4 lock" the file.
    "p4 fstat" on the file. Check that it's locked, by you-the-user,
revert if not.
This will likely need to be done in a language more powerful than DOS
command shell, by the way, since you'll want to examine output of
commands.

Once you have such a script, it's easy to tell your users to install
it as a P4V "custom  tool".  You would tell it to "pass the selected
file as the argument." (Command-line users can just invoke it
directly.)

It is worth doing this, just to see what can be done and what is
reliable (and what is not reliable).  You might not implement this for
your users, but it'll be a very useful exercise  and it might lead you
to the longer-term solution you'll want.

   -Jeff Bowles

ps. If you ask for an enhancement, perhaps asking for "p4 edit -l"
(lock on edit, this time) might be sufficient... if it existed.

On 9/14/07, Greg Whitfield <Greg.Whitfield at lightworkdesign.com> wrote:
> When your user opens a file for edit, he can then lock it. This will
> prevent anyone else from submitting a change - note it does not prevent
> them from checking it out. I know you mentioned locking, but if your
> concern is to prevent unwanted changes in the depot then locking works.
>
> Personally I prefer locking over exclusive checkouts. It's really
> annoying if you can't make that vital test hack in a file because John
> is on holiday or ill.
>
> It's a shame there is no "open" trigger. But I guess that could be
> complicated when opening multiple files in one operation.
>
> On a more general point, I always encourage the use of separate client
> specs for different branches. Don't worry about disk space - it is so
> cheap it costs you more to think about than to buy!
>
> The main "expense" in having the codelines separately synced is in
> setting up your build & execution environment so you can have multiple
> branches co-resident on a single machine without lots of environment
> changes. But this is general good practice anyway.
>
> Greg
> ~~~~
>
>
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Ildefonzo
> Arocha
> Sent: 14 September 2007 12:48
> To: perforce-user at perforce.com
> Subject: [p4] Workspace option: exclusive open
>
> Hi List,
>
> It is Friday and my brain has already started to shutdown :-)
>
> I am about to submit an enhancement request to Perforce, just wanted to
> double check with the gurus and hear what you guys have to say.
>
> What I am needing is an workspace option where, every file checked out
> is locked by the user, so that no other user can change the file.
> Typemap'ping the branch will not help as this only works with new files
> and not with files that are integrated.
>
> To make a long story short, the reason why I need this:
>
> We develop centrally (RDP/Citrix and Linux), we have a main codeline, a
> branch for each version (V1,V2,V3), and each user has its own workspace
> which consists of the main codeline.
>
> Now and then, we have to fix bugs in V1, V2 or V3, this happens
> frequently.  In such case we fix in MAIN and propagate to V1,V2 or V3
> (sometimes vice versa).  In order to do this we need a workspace for
> V1,V2 and V3, however mapping these branches to each users workspace
> would be a big overkill (plus a big waste of disk space).  So what I
> would need is to create one workspace for each branch, and this new
> option "exclusive open" which allows only one user to open a file at the
> time.
>
> Locking the file does not seem help, as this is only checked at submit
> time.
>
> Does this make sense to anyone? Hope it does :-)
>
> Thanks,
> Ildefonzo
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>


-- 
---
Jeff Bowles - jeff.a.bowles at gmail.com