ilya.dogolazky@xxxxxxxxx wrote on Tue, 12 Jun 2012 12:37 +0300:
> Hi Luke!
>
> > #!/bin/sh
> > export P4PORT=localhost:1234
> > mkdir db cli
> > ( cd db && p4d & )
> > sleep 2
> > ( cd cli && EDITOR=: p4 client && date >foo.c &&
> > p4 add foo.c && p4 submit -d 'x' )
> > git-p4 clone //depot@all
>
> I installed p4d on my machine and executed the above script.
> It works, the file foo.c is visible in the copy and one line patch
> is visible by "git log -p". Everything is fine!
>
> Then I realize, that the "git-p4" call in your script is
> communicating with the p4 daemon directly, which is much more simple
> setup than I tried to use before. Then I changed the clone command:
> instead of
> $ git p4 clone //kalma/xxx/yyy@all
> I now tried
> $ git p4 clone //xxx/yyy@all
> after setting P4PORT etc to point to the company's perforce server.
> And it worked!
Fascinating. So //kalma/xxx/yyy is a depot hosted in a p4d that runs
on your local box, but //xxx/yyy is the depot name hosted in
the company's p4d?
> Then I even tried
> $ git p4 clone //xxx@all
> And it worked too (creating a huge git repository with the whole project).
>
> Until today I tried to use the following setup: first clone the
> whole perforce repository with p4 command line client to my machine
> ('kalma' is its name) and then make a git repository by "git-p4
> clone" from this intermediate location (and it seems I did something
> wrong there: files were visible in the intermediate location after
> the first step, but not in the end location after git-p4). I read it
> somewhere in documentation claiming that it's the only way to use
> git-p4. But now I see, that it seems not to be necessary. Please
> clarify, is it okay to skip this intermediate location and use
> git-p4 in the same way as your script does?
I'm completely confused that //kalma/xxx/yyy even appeard to work
at all. Will be interested to see your P4PORT setting when using
that repo.
> And another question, probably connected to above: Now I did this:
> $ git p4 clone //xxx/yyy@all
> $ cd yyy/zzz
> $ edit readme.txt (which was already present there)
> $ git commit readme.txt
> $ git p4 rebase (Current branch master is up to date)
> $ git p4 submit
>
> That last step failed with following messages:
> Submitting change 20073
> ... //xxx/yyy/zzz/readme.txt - warning: cannot submit from
> non-stream client
> No files to submit.
> Submit failed -- fix problems above then use 'p4 submit -c 20073'.
Ooh. You're using the shiny new "streams" feature in p4,
I think. Can you play with "p4 stream" to see if one is
defined on //xxx or //xxx/yyy?.
Could be that the work-around is to use "p4 client" to
set the "Stream" field. This p4 forum post talks about
using "p4 client -s -S ...".
http://forums.perforce.com/index.php?/topic/1139-seeding-streams-from-existing-depots-failed/
which is explained at the bottom of this section:
http://www.perforce.com/perforce/doc.current/manuals/p4guide/06_codemgmt.html#1066766
If you can help us understand the problem a bit better,
a reasonable fix might be to detect this situation in
git-p4 and at least explain how to fix it. Since git-p4
does not create the client used for submit, we don't have
much control over its settings.
-- 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