sam@xxxxxxx wrote on Mon, 09 Mar 2009 15:21 +0100:
> I have modified git and git-p4 to a point where they are usable in
> my work environment. I am now faced with a new problem: Perforce's
> composite workspaces. They allow you to "mount" parts of the repo onto
> other directories, even nonempty ones.
>
> Take the following example repository, where a "framework" project
> contains an example subdirectory with build files and other directories,
> and a "project1" project contains subdirectories that are meant to
> replace the ones in "example":
>
> //work/framework/example/src/
> /include/
> /Makefile
> /...
> //work/project1/src/
> /include/
In perforce terms, your "view mapping" looks like:
//work/framework/example/src/... //client/src/...
//work/project1/src/include/... //client/src/include/...
?
I'm not a pro with p4, but do deal with many-line mappings like
this. Stock git-p4 handles these, except doesn't map correctly to
the right-hand side. I haven't tried to see if it would correctly
use the include files from project1 instead of framework in your
example.
If you can get git-p4 to figure out the mapping correctly, I don't
expect any problems with respect to atomicity of commits. As far as
perforce goes, a server seems to manage its entire p4 space as one
big single project. Similarly with the git side of things---it's
just a matter of getting this mapping correct.
I too hacked the getClientSpec() part of git-p4 to put files into
the correct directories in the git side. My changes are a bit
messy, and may interfere with other usage models, hence not
submitted. Maybe we should make an effort to get this right though.
Do you have any changes to show how you are modifying things?
-- Pete
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
