Re: git-p4 workflow suggestions?

[Sam Hocevar <sam@zoy.org>]

On Wed, Mar 11, 2009, Pete Wyckoff wrote:
> sam@zoy.org 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/...

   Yes, like this. More precisely:

    //work/framework/example/... //client/...
    //work/project1/src/...  //client/src/...
    //work/project1/include/...  //client/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.

   No luck here. If I clone //work with git-p4, I get two separate
/framework and /project1 directories, and the mapping is not done.

   The "solution" I found so far was to clone //work and hack git-p4
so that it ignores //work/framework/example/src, and then symlink
//work/project1/src to //work/framework/example/src. This allows me to
pull changes with a single "git-p4 rebase" command. Unfortunately it
also requires me to clone a full, separate //work p4 workspace in order
to use "git-p4 submit" later, and that's more than 120 GiB wasted.

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

   I'm curious to see your changes. I don't feel I completely understand
the p4 way to do things yet.

   My changes are extremely messy but I will refactor them as time goes.
There is at least one other important thing my git-p4 does, which is not
storing the whole commit in memory. Combined with the patches I sent
last week to this list, it's the only way I can import the p4 repository
we have at work. (See http://zoy.org/~sam/git/clumsily-hacked-git-p4)

   Feel free to contact me in private if you have questions or want
information that may not be mailing-list relevant. I'm all for cleaning
up things and getting a fully featured git-p4. I'm on that project for
at least three years, and there is absolutely no way my blood pressure
can stand that long with Perforce.

Cheers,
-- 
Sam.