On Mon, Jan 25, 2010 at 10:35 PM, Daniel Barkalow <barkalow@xxxxxxxxxxxx> wrote:
> This is probably not particularly appropriate for mainline
> application, and is somewhat buggy, not extensively tested, and
> incomplete. The push support is also currently based on a transport helper
> export design that isn't upstream and I don't like any more; a better
> design is probably to have the core send an "export" command and then a
> gfi stream, but I haven't worked on this.
>
> It has two implementations of the interaction with the Perforce
> server: one that uses the command-line client (and therefore makes a
> ton of separate connections to the server) and one that uses the
> (closed source, vaguely licensed) C++ API. The former does not support
> everything used in push/submit correctly at this point.
>
> It also adds support to the Makefile for building C++ object files and
> linking with a C++ linker. It should be easy to omit entirely for
> builds that don't use p4, and it's at least somewhat out of the way.
>
> The biggest flaw currently is that it doesn't save its analysis of the
> structure of the history, and doesn't have a way to push it out of memory,
> so a long or complex history will run you out of memory or will take a
> long time to do an incremental fetch.
>
> Fetch features:
>
> - following integrations (with some guessing)
> - finding other branches of a codeline
>
> Push features (only with the C++ API):
>
> - works if you don't do anything at all complicated
>
> Signed-off-by: Daniel Barkalow <barkalow@xxxxxxxxxxxx>
<snip>
Hi, and thank you for posting this.
I tried applying it to current master, and got it to compile using the
p4 c++ api.
However, I'm having trouble getting it to run. This is most certainly
my own fault, and I'm guessing it has to do with my .git/config file
setup.
I tried doing 'git init', and making a .git/config file like so:
------------
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[vcs-p4]
port = perforce.mycompany.com:1666
client = toral
[remote "origin"]
vcs = p4
codeline = //depot/path/to/my/existing/test/project
------------
Then, I did 'git fetch', and got a seg fault. I got around it by
commenting out a line:
diff --git a/transport.c b/transport.c
index 7714fdb..5b404f7 100644
--- a/transport.c
+++ b/transport.c
@@ -924,7 +924,7 @@ struct transport *transport_get(struct remote
*remote, const char *url)
ret->url = url;
/* In case previous URL had helper forced, reset it. */
- remote->foreign_vcs = NULL;
+/* remote->foreign_vcs = NULL;*/
/* maybe it is a foreign URL? */
if (url) {
-------------
So - now I get this:
$ GIT_TRANSPORT_HELPER_DEBUG=1 git fetch
Debug: Remote helper: -> capabilities
Debug: Remote helper: Waiting...
Debug: Remote helper: <- import
Debug: Got cap import
Debug: Remote helper: Waiting...
Debug: Remote helper: <- export
Debug: Got cap export
Debug: Remote helper: Waiting...
Debug: Remote helper: <-
Debug: Capabilities complete.
Debug: Remote helper: Waiting...
Debug: Remote helper: <- ? refs/p4/depot/path/to/my/existing/test/project
Debug: Remote helper: Waiting...
Debug: Remote helper: <- ? refs/p4/depot/path/to/my/existing/test/project
Debug: Remote helper: Waiting...
Debug: Remote helper: <-
Debug: Read ref listing.
fatal: Couldn't find remote ref HEAD
-------------
I also tried setting vcs-p4.findbranches to 'true'. The only
difference in the output, is that the "<- ? refs/p4/..." line is just
output once.
So if anyone has a clue for me, I shall, well, cease to be clueless.
-Tor Arvid-
--
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