how to properly import perforce history...

how to properly import perforce history...

[Kevin Green]

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

Asking again... [Re: how to properly import perforce history?]

[Kevin Green]

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

Re: Asking again... [Re: how to properly import perforce history?]

[Simon Hausmann]

[-- Attachment #1: Type: text/plain, Size: 741 bytes --]

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


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Asking again... [Re: how to properly import perforce history?]

[Alex Riesen]

On 6/11/07, Simon Hausmann <simon@lst.de> wrote:
>
> *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
>

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?

Re: Asking again... [Re: how to properly import perforce history?]

[Kevin Green]

On 06/11/07 10:56:33, Simon Hausmann wrote:
> 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).
> 

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

Re: Asking again... [Re: how to properly import perforce history?]

[Simon Hausmann]

[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]

On Monday 11 June 2007 17:44:04 Alex Riesen wrote:
> On 6/11/07, Simon Hausmann <simon@lst.de> wrote:
> > *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
>
> 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Asking again... [Re: how to properly import perforce history?]

[Alex Riesen]

Simon Hausmann, Mon, Jun 11, 2007 20:42:12 +0200:
> On Monday 11 June 2007 17:44:04 Alex Riesen wrote:
> > On 6/11/07, Simon Hausmann <simon@lst.de> wrote:
> > > *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
> >
> > 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.

> > 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)

Re: Asking again... [Re: how to properly import perforce history?]

[Alex Riesen]

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.

[PATCH] git-p4: check for existence of repo dir before trying to create [Was: Asking again... [Re: how to properly import perforce history?]]

[Kevin Green]

On 06/11/07 15:59:30, Simon Hausmann wrote:
> On Monday 11 June 2007 21:44:50 you wrote:
> > On 06/11/07 10:56:33, Simon Hausmann wrote:
> > > *plug* You could try with git-p4 from http://repo.or.cz/w/fast-export.git
> > > . It should be just a matter of calling
> >
> > hmmm....  Failed with this:
> >
> > $ git clone http://repo.or.cz/w/fast-export.git
> > Initialized empty Git repository in /var/tmp/kgreen/dev/fast-export/.git/
> > /ms/dist/fsf/PROJ/git/1.5.2.1/bin/git-clone: line 381: cd:
> > /var/tmp/kgreen/dev/fast-export/.git/refs/remotes/origin: No such file or
> > directory
> > fatal: Not a valid object name HEAD
> >
> > I then tried the mirror I found at the git revision history site:
> >
> > $ git clone http://repo.or.cz/r/fast-export.git
> > Initialized empty Git repository in /var/tmp/kgreen/dev/fast-export/.git/
> > Getting alternates list for http://repo.or.cz/r/fast-export.git
> > Getting pack list for http://repo.or.cz/r/fast-export.git
> > Getting index for pack 66d95396fcacd053b385a4ed71edb2b1bc15e074
> > ...
> >
> >
> > Don't know if they're the same, but I'll give it a shot now...
> 
> The latter seems indeed like the right URL for a HTTP based clone off of 
> repo.or.cz. I would recommend using the git protocol though if possible :)
> 

Not possible unfortunately...

Anyway, grabbed git-p4 and tried it three ways:

1) git-p4 clone //depot/path/repo@all

  I don't like this because it creates a git repository under "repo" subdir.
  To make a long store short, we have a very strict namespace for
  development...  The path ends in src and I'd like the .git repository to be
  under src.  

So, I tried this one level up:

2) git-p4 clone //depot/path/repo@all src

	But that dies with a mkdir error because 'src' already exists.  I want to
	submit a patch, but wanted to check with you first to see if that's the
	desired behaviour (I don't think it should fail though) because maybe you
	want to stop someone from scribbling on an already present git repository?

	I would want to just go for a "if it doesn't exist yet, create it,
	otherwise, forge ahead" behaviour.  I attach the patch after my .sig...

3) Tried without clone:

$ git init
$ git-p4 sync //depot/path/repo@all

	This looks like it's pulling down all the revisions, but it doesn't
	actually put any code in there.  I'm left with the same situation as
	git-p4import.py.
	
	Actually, not even.  I don't even have the commit history...


I would like to get 3 working properly because it's clunky to do #2.  But with
the patch, #2 does what I want and gets me started...

Patch attached.  Please let me know what I'm doing wrong with #3 above...


Thanks

--Kevin


>From c14f906b255a310db0c674ce567fd776aad8f397 Mon Sep 17 00:00:00 2001
From: Kevin Green <Kevin.Green@morganstanley.com>
Date: Mon, 11 Jun 2007 16:48:07 -0400
Subject: [PATCH] git-p4: check for existence of repo dir before trying to create

When using git-p4 in this manner:

git-p4 clone //depot/path/project myproject

If "myproject" already exists as a dir, but not a valid git repo, it fails
to create the directory.

Signed-off-by: Kevin Green <Kevin.Green@morganstanley.com>
---
 git-p4 |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/git-p4 b/git-p4
index e380c14..cababc7 100755
--- a/git-p4
+++ b/git-p4
@@ -1400,7 +1400,8 @@ class P4Clone(P4Sync):
             self.cloneDestination = self.defaultDestination(args)

         print "Importing from %s into %s" % (', '.join(depotPaths), self.cloneDestination)
-        os.makedirs(self.cloneDestination)
+        if not os.path.exists(self.cloneDestination):
+            os.makedirs(self.cloneDestination)
         os.chdir(self.cloneDestination)
         system("git init")
         self.gitdir = os.getcwd() + "/.git"
--
1.5.2.1

Re: Asking again... [Re: how to properly import perforce history?]

[Scott Lamb]

Alex Riesen wrote:
> Simon Hausmann, Mon, Jun 11, 2007 20:42:12 +0200:
>> On Monday 11 June 2007 17:44:04 Alex Riesen wrote:
>>> On 6/11/07, Simon Hausmann <simon@lst.de> wrote:
>>>> *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
>>> 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.

>> 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?

> 
>> 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?

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

Re: [PATCH] git-p4: check for existence of repo dir before trying to create [Was: Asking again... [Re: how to properly import perforce history?]]

[Simon Hausmann]

[-- Attachment #1: Type: text/plain, Size: 1862 bytes --]

On Monday 11 June 2007 22:51:40 Kevin Green wrote:
[...]
> Anyway, grabbed git-p4 and tried it three ways:
>
> 1) git-p4 clone //depot/path/repo@all
>
>   I don't like this because it creates a git repository under "repo"
> subdir. To make a long store short, we have a very strict namespace for
>   development...  The path ends in src and I'd like the .git repository to
> be under src.

Fair enough :)

> So, I tried this one level up:
>
> 2) git-p4 clone //depot/path/repo@all src
>
> 	But that dies with a mkdir error because 'src' already exists.  I want to
> 	submit a patch, but wanted to check with you first to see if that's the
> 	desired behaviour (I don't think it should fail though) because maybe you
> 	want to stop someone from scribbling on an already present git repository?
>
> 	I would want to just go for a "if it doesn't exist yet, create it,
> 	otherwise, forge ahead" behaviour.  I attach the patch after my .sig...

Thanks for the patch. Applied and pushed out.

> 3) Tried without clone:
>
> $ git init
> $ git-p4 sync //depot/path/repo@all
>
> 	This looks like it's pulling down all the revisions, but it doesn't
> 	actually put any code in there.  I'm left with the same situation as
> 	git-p4import.py.
>
> 	Actually, not even.  I don't even have the commit history...

Actually... the import worked just fine, but I admit that it is not obvious 
_where_ the import went. I've just pushed out a change that makes git-p4 sync 
in this case also print out the ref. By default git-p4 sync imports into 
refs/remotes/p4/master, so after the above command a simple

	git branch -r

should print

	p4/HEAD
	p4/master

so you could for example just create a new master branch based on your p4 
import using

	git branch master p4
	git checkout master

I hope this helps :)

Simon

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Asking again... [Re: how to properly import perforce history?]

[Simon Hausmann]

[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]

On Monday 11 June 2007 22:12:32 Alex Riesen wrote:
[...]
> > > 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Asking again... [Re: how to properly import perforce history?]

[Alex Riesen]

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.

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

> >>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?

Re: Asking again... [Re: how to properly import perforce history?]

[Scott Lamb]

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

Re: Asking again... [Re: how to properly import perforce history?]

[Han-Wen Nienhuys]

Simon Hausmann escreveu:
>>             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!

>>> import commands
>>> commands.mkarg ('$foo bar')
" '$foo bar'"


-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: Asking again... [Re: how to properly import perforce history?]

[Alex Riesen]

On 6/11/07, Simon Hausmann <simon@lst.de> 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".