Alex Riesen wrote:
Scott Lamb, Mon, Jun 11, 2007 23:20:43 +0200:
git-p4 clone //depot/project/path [libs/project/path] [rev-range]
I'm not sure I understand the libs/project/path part, ...
Your client contains the mappings. It defines how the pathnames on the
p4 server relate to that on your computer. In the example above file
>from the depot path //depot/project/path can be found in the directory
of the p4 client in the subdirectories libs/project/path.
git-p4 doesn't even use a p4 client, ...
I didn't say: "using p4 client, figure out where to put the files".
I said: _here_ is the mapping, put the files where I told you to.
No, you didn't say. The words you used would make equal sense with "the
tool should look for //depot/project/path in the working copy at
libs/project/path".
Han-Wen implemented also support for importing multiple depot paths at
the same time (and tracking them in one git branch).
And where does he put the depot paths? As they are in depot? How does
this corelate to the setups done by genuine P4 users (the poor souls)
where the mappings are not always 1-to-1 right from the root? Or you
haven't got any?
Could you give a concrete example of what you have and what you are
trying to produce?
Get the p4 file //depot/project/file and put it into git as
libs/project/file.
Okay. Keep in mind that you're the first person to find this important.
The environment I'm working in is not too big and fairly liberal and
reasonably disciplined.
You must be very strange environment indeed. Carefully balanced.
Not that strange. My company's setup is pretty simple, too. The project
I'm working on just uses has each branch under
"//depot/project/BRANCH/...".
It is not a branch (as a "line of development"). It is merely a
directory with server-side backup. Why do people continue call them
branches, I wonder...
You're being deliberately dense, but I'll explain anyway.
We have several branches of our code. We keep each one in Perforce under
//depot/project/BRANCH/... with appropriate integration history between.
We follow the best practices outlined in the Perforce manual. [1] We use
the same terminology as defined in the Perforce manual.
From your comments, I would guess that you have badly mismanaged your
Perforce tree. Since the other people working on the tool apparently
have not, you may have to do your own work to migrate away.
Subversion has a very similar model to Perforce (the main differences
being that svn does not track merge history and does not have a separate
tag system). I have a Subversion repository in which I did not follow
the recommended practices for branching. Who do I blame for that? Me.
Who will fix it? Hopefully me. I may ask for help, but I'll do so with a
better attitude than you.
Maybe your environment is the odd one?
Just what do you think is a client view? Ever wondered what the
right-hand side of lines in the "View:" section is for?
I know what client views are, and I know what they are capable of. I can
say the same thing about symlinks. Is an importer tool broken if it does
not follow a bizarre reorganization of the source working copy through
symlinks?
[1] -
http://www.perforce.com/perforce/doc.072/manuals/p4guide/06_codemgmt.html#1065698
--
Scott Lamb <http://www.slamb.org/>
-
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
