On Wed, Nov 11, 2009 at 1:39 PM, Dmitry Smirnov <divis1969@xxxxxxxxx> wrote:
> Tor Arvid Lund <torarvid <at> gmail.com> writes:
>
>
>> Well, I see what you're trying to do, but I would not want to see that
>> patch in the official script, because some (most?) people (myself, at
>> least) use git-p4 to clone single projects out of a perforce depot
>> that may contain many projects. I do this myself by doing:
>>
>> git p4 clone //depot/path/to/projectX <at> all
>>
>> I usually use one clientspec in perforce, and I do not want to change
>> that... With your patch, I would be in trouble since my clientspec
>> contains "//depot/..." (followed by a lot of lines starting with '-')
>
> Well, does this mean that if you try to sync the client in perforce (visual or
> command line), you will sync all the projects?
Yes, but I generally try to not use perforce, but git instead :-)
> In that case, git p4 will require significant effort to satisfy both of us :-)
> Unfortunatly, it seems I'm in minory group of git-p4 users...
I don't know, but if I were to guess, then yes, you probably are... If
you have a complex perforce client spec setup, then there may of
course be problems that git-p4 might not solve for you. Since nobody
has volunteered to implement the features you describe yet, I believe
that most of us git-p4 users have fairly simple client spec setups.
For me, most projects in p4 are such that I can give one root
directory to "git p4 sync", and it works for me. I of course have
several git projects that sync from the same p4 server (only with
different root dirs). In cases where you have dependencies between
such projects, you should maybe read about git submodules - or maybe
googles "repo" script (search for "google repo git"). I don't know
much about any of these, other than 'they exist, and seemingly try to
solve such issues' :-/
> i would propose to use both command-line arguments and a client spec
> to create a correct filter of what should be synced/cloned.
> BTW, it looks this script does not honor neither the order of paths
> in the spec (which can be important) nor mapping of the files to a local tree.
When you have a client spec like:
//depot/A/...
-//depot/A/B/...
//depot/A/B/C/...
... git-p4 sorts these paths by length. For a given filename, it finds
the longest path that matches that files directory, and if that path
starts with a '-', the file is not synced (for a file
"//depot/A/B/myfile.c" it gets a match on "-//depot/A/B/...", and
myfile.c is not synced, but the file "//depot/A/B/C/myotherfile.c" it
matches "//depot/A/B/C/...")
Do you have an example that shows how it might fail?
And no, git-p4 does not care about the local mappings, it reads only
the server part.
-Tor Arvid-
>> If you want to fix it, you might want to rename clientSpecDirs to
>> clientSpecEntries or something like that.
>
> For now, I just commented out two lines in the run() procedure:
> #if not p.endswith("/"):
> # p += "/"
>
>> Btw... Am I understanding correctly what it is you wish to accomplish?
>> I'm guessing that you have a perforce server with a client spec set
>> up, and you want to sync everything on the entire server according to
>> that client spec?
>
> yes. Client spec completely defines the project layout for me.
> It contains paths to some components that are mapped to the
> client working tree.
> Just if your CS contain
>
> //depot/path/to/projectX/... //CLIENT/...
>
>
>
> --
> 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
>
--
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