[p4] Workspace option: exclusive open

[Rick Macdonald]

Oh, I see now, it's only the integration targets (V1/V2/V3) that you 
want to share, not the mainline. That is fairly clear in your original 
post. I do what others mentioned, which is to have those in each 
person's view, mapped to private workspace, but nobody ever syncs it all.

...RickM...

Ivey, William wrote:
>   
>> Do I have this right (I hope I don't!), that you have one
>> physical directory tree on disk, with multiple users editing
>> files at the same time (but different files), compiling files
>> and running tests?
>>     
>
> No, not at all. (But see below.)
>
> Every user has (potentially) access to every branch within
> their own, single, workspace. There's nothing about Perforce
> that requires there to be a workspace for each branch, and
> it's usually not efficient to work that way. Wildcards make
> it simple to map as much as you want with just a couple of
> lines in the view section.
>
> For example, when I make a change to main, and need to
> integrate it to V1, I just do it. All of the branches are
> visible to me at all times, and any of them I want on my
> system can be synced at will. If I don't want the extra files
> I just do the integration on the server with the option that
> doesn't copy unnecessary files to my workspace. (I can always
> remove files I don't need, too.)
>
> However, it is possible to set up a common workspace with a
> single client and let multiple users access it. Each user
> will have their own default changelist to work with so it's
> not really that confusing. For most things, as far as I know,
> this effectively locks files that others are using since you
> normally can't check out a file twice to the same client.
>
> I don't see much advantage to that over every user just
> expanding their view to include all the branches they need
> to deal with, and there can be some permission issues with
> it, so I don't recommend it except for very special cases.
>
> As far as shared object files go, you could check them into
> Perforce once you know they are good. (The +Sn file type is
> useful for that.) This is similar to something like Mavin's
> repository, but I think it's cleaner. We do test builds
> every hour or 90 minutes, and check in the results (to a
> dedicated server) twice a day. (QA picks up images for
> testing from that server.) Perforce makes a dandy
> distribution system for almost any file, but most people
> don't seem to use it beyond just source control. (I've had
> developers roll their eyes at me for suggesting it, then
> spend weeks reinventing its wheels and never reaching the
> same level of reliability or convenience.)
>
> -Wm
>
>
>
>
> -----Original Message-----
> From: Rick Macdonald [mailto:rickmacd at shaw.ca] 
> Sent: Friday, September 14, 2007 12:48 PM
>
> William -
>
> Do I have this right (I hope I don't!), that you have one physical 
> directory tree on disk, with multiple users editing files at the same 
> time (but different files), compiling files and running tests?
>
> If that is right, this is an alternative to having each user build the 
> entire tree in a private workspace in order to save overkill and disk
> etc?
>
> If that is right, who syncs and builds everything in this workspace for 
> everybody, and how often? How do you coordinate all this going on in the
>
> one directory tree at the same time? Wouldn't my work link in your 
> untested object files that you've just compiled?
>
> I've assumed what I do is common, but I've never asked outside the 
> company. I have a full nightly (successful) build of the mainline and 
> various releases that are on a file server visible to everyone. Each 
> programmer has a tiny workspace of just the libraries he is working on 
> at the moment. The programmer build environment and tool is such that 
> everything needed to compile and link the files in his workspace that 
> are _not_ in his workspace (header files, other libraries, etc) comes 
> from the appropriate shared build on the fileserver. No overkill, no 
> wasted space, and we're each isolated from other people's work. I admit 
> the programmer's build environment and tool (scripts and a single 
> Makefile that I invented) are not trivial.
>
> What do other people out there do?
>
> Our programmers who choose or need to work on Windows do indeed have to 
> sync and build the whole world themselves. I admit I ignore anything to 
> do with Windows and have only made life reasonable for programmers on 
> UNIX platforms (only _partly_ due to my lack of Windows expertise ;-).
>
> ...RickM...
>
> Ivey, William wrote:
>   
>> You don't really need a workspace for every branch, just
>> a workspace that encompasses all of the branches. Then the
>> users just select what branches they want to sync at any
>> given time.
>>
>> If your depot looks like this:
>> 	//depot/main/...
>> 	//depot/v1/...
>> 	//depot/v2/...
>>
>> Then you map it like this in your client:
>> 	//depot/*/... /myClient/*/...
>>
>> That works for us, but might not be suited to every situation.
>>
>> -Wm
>>
>>
>> -----Original Message-----
>> From: perforce-user-bounces at perforce.com
>> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Ildefonzo
>> Arocha
>>
>> 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
>>
>>   
>>     
>
>