[p4] [Newbie]: Mapping one depot to multiple locations in sameworkspace

Ivey, William william_ivey at bmc.com
Tue Mar 31 12:09:42 PDT 2009


One simple case was classic InstallShield. It was not very versatile
in looking for standard files such as icons, EULAs, etc. That meant
creating copies of each of these within a dozen or more directories
across our release  branches. Updating them was tedious (and
legal was always tweaking the EULA).

Since then I've encountered other cases where bending the 1:1
rule would have been the easiest, most maintainable solution.
(Or sometimes just the solution of least resistance which is not
to be discounted when schedules are tight and resources are
unavailable.)

That said, it's not been a major pain point to work around it.

-Wm

________________________________
From: Matt Janulewicz [mailto:matt.janulewicz at lucasfilm.com]
Sent: Tuesday, March 31, 2009 1:30 PM
To: Philip Panyukov
Cc: Ivey, William; perforce-user at perforce.com
Subject: Re: [p4] [Newbie]: Mapping one depot to multiple locations in sameworkspace

A scenario where the same code/library/etc. is branched to multiple projects and never changed always raises a red flag with me. I wonder why there is often a 'need' to do this instead of making a common area for the actual common code and having multiple projects refer to that.

I have seen very few, rare cases where it seemed like this was the only option (MS VisualStudio 2003 web projects come to mind) but there were always other alternatives.

As a 'CM guy' I try to provide 'one truth' to my users and can't recall any situation where branching a 'stable' library/tool to every project that uses it resulted in an easier path to development. Changes are eventually made to one copy of the tool, not properly propagated to the 17 copies of it, then you basically have no way to baseline your code, you create a maintenance nightmare, etc., which could have been prevented with very small tweaks to the code or architecture. It's usually a case for refactoring.

In the case where multiple legitimate versions of a tool are needed for different projects, I've always found it easier to include them all in the common area and tweak client specs, rather than maintain multiple branches of the same thing.

If your tools are significantly large, it seems hard to justify spending the time to sync 3 or 4 copies of the same 100 megs of libraries if you work on multiple projects (multiplied by the number of developers you have.)

Maybe I'm not experienced enough (12 years in the SCM field) or have been lucky, but what are the legitimate arguments for maintaining multiple, identical code trees? So far I haven't come across a legitimate reason for it.


-Matt


Philip Panyukov wrote:

Yes that's right, I was referring to branch specs, not client views.
But this was done only to highlight that the limitation of
"one-to-one" mapping exists in other places besides client views.

To answer Jeff's question of "When you need to push to a sixth
project, will you use that proposed branch-spec? More importantly,
will you remember to push only to the sixth project, avoiding
inadvertently repopulating the original five projects?".

I would say the answer is "Most likely yes".

The reason for that is that Perforce will (most likely) say "all
revisions are integrated" for projects 1 to 5, and only project 6 will
show up as needing integration.

The more real scenarios for me would be:

1. I am working on project X, Y and Z. I want to ensure I am using the
latest set of tools. To make sure I do, run p4 integrate -b TOOLS
//projectX/... //projectY/... //projectZ/....

2. If I were someone overseeing general development activities within
organisation, I would want to know: are there projects which use
out-of-date versions of tools?  If so, make sure those projects
migrate to new version at some point.  With one global branch-spec, I
would just "p4 interchanges -b TOOLS" and the answer is there. With
current capabilities, I have to go through each branch-spec etc etc.
Doable, but not so elegant.

This applies to many things, not just tools. These are libraries,
dependencies and things like this.  In fact, libraries and
dependencies are of more concern to me than tools.

The client views and "one-to-many" mappings are of course more tricky
but even here there were times I briefly wished it was possible. Don't
remember what it was exactly but it always was "use same file in
multiple places without branching" type of thing.  The dangers of such
mappings in client views are probably no greater than having sparse
branches.  May be confusing, but only if files are edited and
submitted, but probably perfectly fine for libraries, dependencies,
tools and such.  I can perfectly see the use of such feature.


Philip


2009/3/31 Ivey, William <william_ivey at bmc.com><mailto:william_ivey at bmc.com>:
> I believe Philip is talking about branch specs and not client views,
> so the ability to do mappings like that would have some utility and
> only limited issues. Of course it only works when you name the
> destination, or if you could use it to "broadcast" an integration.
> (I've had cases where that would have been useful.)
>
> -Wm
>
>
> -----Original Message-----
> From: perforce-user-bounces at perforce.com<mailto:perforce-user-bounces at perforce.com> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Rick Macdonald
> Sent: Tuesday, March 31, 2009 9:00 AM
>
>
> Here's my guess:
>
> If you open //tools/NAnt/doit for edit, I think Perforce only stores the
> fact that the file is open on the named clientspec (workspace). Which
> one would that be? There are three to choose from. Which one gets its
> file permissions changed to read-write if you open with depot syntax
> instead of local file syntax? Removing the ability to use depot syntax
> to support this would be a bit messy, I think.
>
> The opposite case is similar: mapping multiple depot directories to one
> local disk directory. If you add a file using local disk syntax, it
> wouldn't know which area of the depot to add the the file to.
>
> I have a ton of shared tools, but they are in a shared development area
> available to all projects, usable by execution "PATH" or by well-known
> location that includes an environment variable override for the path
> prefix. I'm sure you have a good reason not to do this. I'm glad I
> don't!  ;)
>
> Rick
>
> Philip Panyukov wrote:
>> I too found this to be a limitation is some cases.  One recent one was
>> to set up one single branch spec for all the tools we use in all
>> projects and then use that spec to integrate new versions of tools
>> into projects.
>>
>> TOOLS branch
>> //tools/NAnt/... //projA/tools/NAnt/...
>> //tools/NAnt/... //projB/tools/NAnt/...
>> //tools/NAnt/... //projC/tools/NAnt/...
>>
>
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com<mailto:perforce-user at perforce.com>
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>

_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com<mailto:perforce-user at perforce.com>
http://maillist.perforce.com/mailman/listinfo/perforce-user



More information about the perforce-user mailing list