[p4] Workspace option: exclusive open

[Ivey, William]

Again, that's not quite it.

We don't use any shared workspaces. We've set it up as you say,
with everything in private workspaces. And, yes, you only sync
what you need, if anything.

-Wm


-----Original Message-----
From: Rick Macdonald [mailto:rickmacd at shaw.ca] 
Sent: Friday, September 14, 2007 2:52 PM
To: Ivey, William
Cc: perforce-user at perforce.com
Subject: Re: [p4] Workspace option: exclusive open

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
>>
>>   
>>     
>
>