From: Kevin Green <hidden> Date: 2016-06-15 22:43:14
Very new to git. Was hoping this would be much more straightforward and I'm
assuming I'm just missing something fundamentally easy.
I'm using git-p4import.py which came with my release of git.
I have a small project I'd like to move from perforce to git ( 111 files, 165
revisions ).
I've used a number of different approaches to do this, all of them resulting
in my files being deleted.
1)
$ git init
$ git-p4import //depot/path master
bombs out with missing .git/index
2)
$ p4 sync ...
$ git init
$ git add .
$ git commit
$ git-p4import --stitch //depot/path
This imports all the comment history, but deletes all of my files!!
3)
$ p4 sync ...
$ git init
$ git add .
$ git commit
$ git-p4import //depot/path new
### new branch with no files, but all my files in master
$ git checkout master
$ git merge new
### Now I see it deleting all of my files, but it pulls in all of the history.
NOTE: All of the commits pulled in have no file information associated with
them...
What am I missing?
Thanks
--Kevin
From: Kevin Green <hidden> Date: 2016-06-15 22:43:15
Reading this again, the subject was probably misleading... Sorry for that.
In the meantime I've been scouring the archives looking for the proper way to
import p4 history into a project.
I'm attempting to use git-p4import.py as that's what came with my version of
git. I ran into the problems below.
How can I properly migrate a project from perforce to git?
Thanks
--Kevin
On 06/08/07 16:22:36, Kevin Green wrote:
Very new to git. Was hoping this would be much more straightforward and I'm
assuming I'm just missing something fundamentally easy.
I'm using git-p4import.py which came with my release of git.
I have a small project I'd like to move from perforce to git ( 111 files, 165
revisions ).
I've used a number of different approaches to do this, all of them resulting
in my files being deleted.
1)
$ git init
$ git-p4import //depot/path master
bombs out with missing .git/index
2)
$ p4 sync ...
$ git init
$ git add .
$ git commit
$ git-p4import --stitch //depot/path
This imports all the comment history, but deletes all of my files!!
3)
$ p4 sync ...
$ git init
$ git add .
$ git commit
$ git-p4import //depot/path new
### new branch with no files, but all my files in master
$ git checkout master
$ git merge new
### Now I see it deleting all of my files, but it pulls in all of the history.
NOTE: All of the commits pulled in have no file information associated with
them...
What am I missing?
Thanks
--Kevin
From: Simon Hausmann <hidden> Date: 2016-06-15 22:43:15
On Monday 11 June 2007 16:25:25 Kevin Green wrote:
Reading this again, the subject was probably misleading... Sorry for that.
In the meantime I've been scouring the archives looking for the proper way
to import p4 history into a project.
I'm attempting to use git-p4import.py as that's what came with my version
of git. I ran into the problems below.
How can I properly migrate a project from perforce to git?
*plug* You could try with git-p4 from http://repo.or.cz/w/fast-export.git . It
should be just a matter of calling
git-p4 clone //depot/path
or
git-p4 clone //depot/path@all
(the former if you just want perforce #head, the latter if you want to import
all revisions).
Simon
Can I suggest you add a target directory mapping to your tool?
Something like:
git-p4 clone //depot/project/path [libs/project/path] [rev-range]
The way Perforce handles branches and directories leads to
the problem that it actually cannot cleanly support neither of
them, and it is very hard to untangle a big repo which
historically has had many projects living in it.
Especially if some idiot actually tried to "do branching".
And, BTW, don't you have a small problem with filenames with
spaces and quoting?
From: Kevin Green <hidden> Date: 2016-06-15 22:43:15
On 06/11/07 10:56:33, Simon Hausmann wrote:
On Monday 11 June 2007 16:25:25 Kevin Green wrote:
quoted
Reading this again, the subject was probably misleading... Sorry for that.
In the meantime I've been scouring the archives looking for the proper way
to import p4 history into a project.
I'm attempting to use git-p4import.py as that's what came with my version
of git. I ran into the problems below.
How can I properly migrate a project from perforce to git?
*plug* You could try with git-p4 from http://repo.or.cz/w/fast-export.git . It
should be just a matter of calling
git-p4 clone //depot/path
or
git-p4 clone //depot/path@all
(the former if you just want perforce #head, the latter if you want to import
all revisions).
Thanks... I'll try this today and post back on my experience. From your
usage example here, it seems to behave the way I thought git-p4import.py
would.
Is git-p4import.py still used and maintained? I submitted a patch to fix
something trivial on Friday, but didn't here any response to that either,
which led me to believe that it's not the tool being used most often for
p4->git migration...
--Kevin
Can I suggest you add a target directory mapping to your tool?
Something like:
git-p4 clone //depot/project/path [libs/project/path] [rev-range]
I'm not sure I understand the libs/project/path part, but the revision range
can be specified in p4-like syntax as part of the depot path. For example
git-p4 clone //depot/path@12,435
to import from revision 12 up to 435. The revision range is more or less
passed directly to "p4 changes", with the exception of "@all".
Han-Wen implemented also support for importing multiple depot paths at the
same time (and tracking them in one git branch).
The way Perforce handles branches and directories leads to
the problem that it actually cannot cleanly support neither of
them, and it is very hard to untangle a big repo which
historically has had many projects living in it.
Especially if some idiot actually tried to "do branching".
I agree, even with a lot of discipline it's very hard to do a 100% accurate
import with logical branches.
The environment I'm working in is not too big and fairly liberal and
reasonably disciplined. I'm using p4 branch mappings to "map" some branches
from perforce to git, which for sure isn't perfect but works overall fine. Of
course that doesn't cover p4 integration changes, but just for tracking
multiple "logical" p4 branches it works great (for me at least :).
And, BTW, don't you have a small problem with filenames with
spaces and quoting?
I'm not aware of any problems. For example in our depot we have filenames with
spaces in them and they appear just fine in my git import. Did you run into
any specific case? It could very well be that there's a bug somewhere that
I'm just not hitting myself, so I'm curious :)
Simon
Can I suggest you add a target directory mapping to your tool?
Something like:
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.
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?
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.
quoted
And, BTW, don't you have a small problem with filenames with
spaces and quoting?
I'm not aware of any problems. For example in our depot we have filenames with
spaces in them and they appear just fine in my git import. Did you run into
any specific case? It could very well be that there's a bug somewhere that
I'm just not hitting myself, so I'm curious :)
No, I just looking at the source. Does python have some magic for
running programs with system() when passed a format string? Like here:
for f in filesToAdd:
system("p4 add %s" % f)
for f in filesToDelete:
system("p4 revert %s" % f)
system("p4 delete %s" % f)
BTW, sometimes you quote the names, but obviously wrong (think about
filenames containing double quotes):
system("p4 edit \"%s\"" % path)
editedFiles.add(path)
From: Alex Riesen <hidden> Date: 2016-06-15 22:43:15
Kevin Green, Mon, Jun 11, 2007 18:41:27 +0200:
Is git-p4import.py still used and maintained?
Not really: there is only 5 changes which touch the file and only two
of them have something to do with the import.
I submitted a patch to fix something trivial on Friday, but didn't
here any response to that either, which led me to believe that it's
not the tool being used most often for p4->git migration...
That's not the tool. It is the migration from p4 to anything which
does not happen too often: this company did very good job tying the
customers to this product. Once you reached some critical mass in
your perforce repo you cannot simply stop using it and go with
something else. Not without much pain, anyway.
Getting the development history out of it is the hardest. I'd say it
is impossible, as the states of development directories, unloaded in
"clients", are fluid and not recoverable after they are changed.
Imagine git with just index and no object database support.
Can I suggest you add a target directory mapping to your tool?
Something like:
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, so the result is simply as it was
on the server. It just does a "p4 print" on depot paths.
quoted
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?
quoted
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/...". Maybe your environment is the odd one?
quoted
quoted
And, BTW, don't you have a small problem with filenames with
spaces and quoting?
I'm not aware of any problems. For example in our depot we have filenames with
spaces in them and they appear just fine in my git import. Did you run into
any specific case? It could very well be that there's a bug somewhere that
I'm just not hitting myself, so I'm curious :)
No, I just looking at the source. Does python have some magic for
running programs with system() when passed a format string? Like here:
for f in filesToAdd:
system("p4 add %s" % f)
for f in filesToDelete:
system("p4 revert %s" % f)
system("p4 delete %s" % f)
BTW, sometimes you quote the names, but obviously wrong (think about
filenames containing double quotes):
system("p4 edit \"%s\"" % path)
editedFiles.add(path)
No, there's no magic. I can't imagine how these could work properly with
complex filenames. They also don't do any checking of return values. I'm
planning on sending in patches to make git-p4 use the Python subprocess
module to do this better (as I did for git-p4import.py). It might take
me a while to get to that item on my todo list, though - rather busy at
work right now.
--
Scott Lamb <http://www.slamb.org/>
From: Simon Hausmann <hidden> Date: 2016-06-15 22:43:15
On Monday 11 June 2007 22:12:32 Alex Riesen wrote:
[...]
quoted
quoted
And, BTW, don't you have a small problem with filenames with
spaces and quoting?
I'm not aware of any problems. For example in our depot we have filenames
with spaces in them and they appear just fine in my git import. Did you
run into any specific case? It could very well be that there's a bug
somewhere that I'm just not hitting myself, so I'm curious :)
No, I just looking at the source. Does python have some magic for
running programs with system() when passed a format string? Like here:
for f in filesToAdd:
system("p4 add %s" % f)
for f in filesToDelete:
system("p4 revert %s" % f)
system("p4 delete %s" % f)
Ooops, indeed. Makes me realizes that I've never actually submitted files with
spaces in the name :). For now I've quoted them with double quotes like in
the other places, which is better than nothing. Thanks for spotting!
BTW, sometimes you quote the names, but obviously wrong (think about
filenames containing double quotes):
system("p4 edit \"%s\"" % path)
editedFiles.add(path)
Indeed, for file names with double quotes that doesn't work. I guess I'll have
to change that to subprocess.Popen then :)
Simon
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.
quoted
quoted
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.
quoted
quoted
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...
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'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".
quoted
quoted
quoted
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.
quoted
quoted
quoted
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.
quoted
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?
Ooops, indeed. Makes me realizes that I've never actually submitted files with
spaces in the name :). For now I've quoted them with double quotes like in
the other places, which is better than nothing. Thanks for spotting!
From: Alex Riesen <hidden> Date: 2016-06-15 22:43:15
On 6/11/07, Simon Hausmann [off-list ref] wrote:
Ooops, indeed. Makes me realizes that I've never actually submitted files with
spaces in the name :). For now I've quoted them with double quotes like in
the other places, which is better than nothing. Thanks for spotting!
Running 'p4 print' the code also does not check for code "error",
and there may be other places which have to check for errors.
BTW, I have never seen code "text". It is always "binary" for file data,
for text files the type in code-stat element is just set to "text".