git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pete Wyckoff <pw@padd.com>
To: Sam Hocevar <sam@zoy.org>
Cc: git@vger.kernel.org
Subject: Re: git-p4 workflow suggestions?
Date: Wed, 11 Mar 2009 05:58:05 -0700	[thread overview]
Message-ID: <20090311125805.GA28155@padd.com> (raw)
In-Reply-To: <20090309142108.GK12880@zoy.org>

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

?

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

  parent reply	other threads:[~2009-03-11 12:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-09 14:21 git-p4 workflow suggestions? Sam Hocevar
2009-03-10  7:15 ` Christian Couder
2009-03-10  9:57   ` Sam Hocevar
2009-03-11  7:03     ` Christian Couder
2009-03-11 12:58 ` Pete Wyckoff [this message]
2009-03-16 18:01   ` Sam Hocevar
2009-03-17 15:18     ` Pete Wyckoff
2009-03-20 10:31       ` Sam Hocevar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090311125805.GA28155@padd.com \
    --to=pw@padd.com \
    --cc=git@vger.kernel.org \
    --cc=sam@zoy.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).