[p4] How to handle VSS File sharing capability in perforce?

Wedig, Sean WedigSean at bfusa.com
Fri Jul 7 06:49:09 PDT 2006


To be fair, I'm fairly new to Perforce, but I don't believe that you can
do anything directly like sharing code as in VSS.

A solution I've found for shared code that you want statically linked is
to have a central location for it in the repository, so that the shared
code is its own "project", even if the code doesn't exist as a DLL or
whatnot.  Then, each project that uses that code integrates from the
shared directory into their own projects.

It's not quite the same, but it's a safer alternative, I think.  A
developer has to manually pull (integrate from) the shared area in order
to grab the code.  Thus, their individual projects remain in a more
steady state until they feel it is necessary or good to update the
shared code.

For organizational purposes, I relegate that shared code into an
externals directory in the trunk.  All in all, it's like so:

//depot/SharedCode1
  - /Trunk

//depot/SharedCode2
  - /Trunk

//depot/SharedCompiledLib1

//depot/SharedCompiledLib2

//depot/MyProj
  - /Trunk
    - /Externals
      - /SharedCode1
      - /SharedCode2
        ...
      - /SharedCompiledLib1
      - /SharedCompiledLib2
        ...
    - /MySource


It just makes it a little cleaner to track what code is "mine", and what
is "theirs".

When I want to update MyProj, I'm doing an integration like

//depot/SharedCode1/Trunk/...
//depot/MyProj/Trunk/Externals/SharedCode1/...

In essence, the SharedCode# directories become project-private branches
of the shared code areas.  If I really must make changes in the shared
code, I can make changes there, then merge them back into the SharedCode
mainline.  Everyone is protected from the "hubbub of development" in the
shared mainlines until we explicitly decide to accept changes.


This is a sort of crude patch to share code that is basically unpackaged
and un-versioned.  The code is not treated like a shared library, but
just an amorphous blob.  A better modification, in my opinion, would be
to treat the shared code groups as actual deliverables, so they have a
release cycle as well.  Then people can use a particular "released"
version of the shared code, and be sure it has certain compatibility or
stability standards (if you track that).

It gets a little bit more tricky if you have multiple levels of
dependencies, and you need to watch for too much copied code.  For
example, if SharedCode2 also relied on SharedCode1, and so had its own
Externals directory, you may need to resolve where what goes and how
things reference each other in MyProj.

-Sean Wedig
 


-----Original Message-----
Date: Thu, 6 Jul 2006 09:06:47 -0500
From: "Neeta ROY" <Neeta.ROY at na.biomerieux.com>
Subject: Re: [p4] How to handle VSS File sharing capability in
	perforce?
To: "Weintraub, David" <david.weintraub at bofasecurities.com>
Cc: perforce-user at perforce.com
Message-ID:
	
<OF95DB29E8.6932C9E3-ON862571A3.004CFD65-862571A3.004EA36D at biomerieux.co
m>
	
Content-Type: text/plain; charset=us-ascii


I totally agree with what you are saying here, David. In our St. Louis
office where I am located and I manage code, we have stayed away but
there
are some legacy code and small projects that are resisting from moving
from
VSS to Perforce till I find them a solution to file sharing.

My goal is to move them to Perforce.

Using Perforce, how do I accomplish same. Is there a way? I thought I
would
ask the community before I say there is no way !!!

Regards,
Neeta Roy




More information about the perforce-user mailing list