From: Tor Arvid Lund <torarvid@gmail.com>
To: Ian Wienand <ianw@vmware.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH] Support different branch layouts in git-p4
Date: Tue, 8 Feb 2011 00:27:12 +0100 [thread overview]
Message-ID: <AANLkTimGKc4MTwb=AnZ_Bv1EGS7yfgrFupxBOVVSm4s8@mail.gmail.com> (raw)
In-Reply-To: <4D4F3738.7010603@vmware.com>
On Mon, Feb 7, 2011 at 1:05 AM, Ian Wienand <ianw@vmware.com> wrote:
> On 04/02/11 16:37, Tor Arvid Lund wrote:
>> For starters, I don't think that I like git-p4 being taught to solve
>> problems that seem to be caused by a poor/unfortunate perforce layout.
>
> I do think this //depot/project/branch type layout is pretty typical,
> although I admit I don't have a lot of experience with alternative p4
> setups.
You may be right, although I suspect that
//depot/department/project/branch may be equally typical. At my
$dayjob, we have gone through several "reorganizations" of the
perforce layouts. I'm the guy that never likes any of them ;)
>> A solution which I think would work well for everyone, is if files
>> would be placed according to the right-hand patterns in the
>> client-spec.
>
> I did consider this at first. My only issue is that it is a bit
> confusing to use the client spec for filtering (and in this case
> re-writing), but not for actually selecting the depots to clone, which
> I still need to replicate on the command line. However that is a much
> larger change.
>
> What do you think of this one?
In general, me thinks me likes it :-)
(and it turned out much smaller than I would have originally guessed)
I should probably mention that I haven't tested your patch at all. I
will have a pretty rough week at work, so it would be great if anyone
else feels like chiming in on this one... But I have some quick
observations below:
> ---
>
> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
> index 04ce7e3..eb9620c 100755
> --- a/contrib/fast-import/git-p4
> +++ b/contrib/fast-import/git-p4
> @@ -878,6 +878,7 @@ class P4Sync(Command):
> self.cloneExclude = []
> self.useClientSpec = False
> self.clientSpecDirs = []
> + self.clientName = None
>
> if gitConfig("git-p4.syncFromOrigin") == "false":
> self.syncWithOrigin = False
> @@ -910,6 +911,22 @@ class P4Sync(Command):
> return files
>
> def stripRepoPath(self, path, prefixes):
> + if self.useClientSpec:
> +
> + # if using the client spec, we use the output directory
> + # specified in the client. For example, a view
> + # //depot/foo/branch/... //client/branch/foo/...
> + # will end up putting all foo/branch files into
> + # branch/foo/
> + for val in self.clientSpecDirs:
> + if path.startswith(val[0]):
> + # replace the depot path with the client path
> + path = path.replace(val[0], val[1][1])
> + # now strip out the client (//client/...)
> + path = re.sub("^(//[^/]+/)", '', path)
> + # the rest is all path
> + return path
> +
> if self.keepRepoPath:
> prefixes = [re.sub("^(//[^/]+/).*", r'\1', prefixes[0])]
>
> @@ -1032,7 +1049,7 @@ class P4Sync(Command):
> includeFile = True
> for val in self.clientSpecDirs:
> if f['path'].startswith(val[0]):
> - if val[1] <= 0:
> + if val[1][0] <= 0:
> includeFile = False
> break
>
> @@ -1474,20 +1491,36 @@ class P4Sync(Command):
> temp = {}
> for entry in specList:
> for k,v in entry.iteritems():
> + if k.startswith("Client"):
> + self.clientName = v
> +
> if k.startswith("View"):
> if v.startswith('"'):
> start = 1
> else:
> start = 0
> index = v.find("...")
> +
> + # save the "client view"; i.e the RHS of the view
> + # line that tells the client where to put the
> + # files for this view.
> + cv = v[index+4:] # +4 to remove previous '... '
This feels less robust than what we might want. Isn't the format of a
client-spec line either:
-?//depot/path[/...]\s+//client/path[/...]\n
or
-?"//depot/path with spaces/path[/...]"\s+"//client/path with spaces/path[/...]"
.. where -? means an optional '-' char, and \s+ is
'whatever-length-and-kind-of-whitespace'. I'm just guessing from
memory regarding these patterns, but assuming that the section
separator is exactly the string '... ' seems risky, no? :)
> + cv_index = cv.find("...")
> + cv=cv[:cv_index]
What if a line doesn't end with "..." ? Maybe add an "if cv_index >= 0"
> +
> + # now save the view; +index means included, -index
> + # means it should be filtered out.
> v = v[start:index]
> if v.startswith("-"):
> v = v[1:]
> - temp[v] = -len(v)
> + include = -len(v)
> else:
> - temp[v] = len(v)
> + include = len(v)
> +
> + temp[v] = (include, cv)
> +
> self.clientSpecDirs = temp.items()
> - self.clientSpecDirs.sort( lambda x, y: abs( y[1] ) - abs( x[1] ) )
> + self.clientSpecDirs.sort( lambda x, y: abs( y[1][0] ) - abs( x[1][0] ) )
>
> def run(self, args):
> self.depotPaths = []
> diff --git a/contrib/fast-import/git-p4.txt b/contrib/fast-import/git-p4.txt
> index 49b3359..e09da44 100644
> --- a/contrib/fast-import/git-p4.txt
> +++ b/contrib/fast-import/git-p4.txt
> @@ -191,6 +191,11 @@ git-p4.useclientspec
>
> git config [--global] git-p4.useclientspec false
>
> +The P4CLIENT environment variable should be correctly set for p4 to be
> +able to find the relevant client. This client spec will be used to
> +both filter the files cloned by git and set the directory layout as
> +specified in the client (this implies --keep-path style semantics).
> +
> Implementation Details...
> =========================
>
>
Aight. I need some sleep now. Nice work so far, Ian! :)
-- Tor Arvid
next prev parent reply other threads:[~2011-02-07 23:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-01 22:59 [PATCH] Support different branch layouts in git-p4 Ian Wienand
2011-02-05 0:37 ` Tor Arvid Lund
2011-02-07 0:05 ` Ian Wienand
2011-02-07 23:27 ` Tor Arvid Lund [this message]
2011-02-09 3:46 ` Ian Wienand
2011-02-10 13:43 ` Pete Wyckoff
2011-02-08 1:22 ` Pete Wyckoff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='AANLkTimGKc4MTwb=AnZ_Bv1EGS7yfgrFupxBOVVSm4s8@mail.gmail.com' \
--to=torarvid@gmail.com \
--cc=git@vger.kernel.org \
--cc=ianw@vmware.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).