All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Vitor Antunes <vitor.hda@gmail.com>
Cc: Luke Diamand <luke@diamand.org>, git@vger.kernel.org
Subject: Re: [PATCH 0/2] git-p4: Improve client path detection
Date: Sun, 12 Apr 2015 20:40:58 -0700	[thread overview]
Message-ID: <xmqqsic44rw5.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20150405235759.392c0f2b@pt-vhugo> (Vitor Antunes's message of "Sun, 5 Apr 2015 23:57:59 +0100")

Vitor Antunes <vitor.hda@gmail.com> writes:

> Luke Diamand <luke@diamand.org> wrote on Sun, 05 Apr 2015 20:27:11 +0100
>> On 28/03/15 12:28, Vitor Antunes wrote:
>> > I'm adding a test case for a scenario I was confronted with when using branch
>> > detection and a client view specification. It is possible that the implemented
>> > fix may not cover all possible scenarios, but there is no regression in the
>> > available tests.
>>
>> Vitor, one thing I wondered about with this part of the change:
>>
>> -            if entry["depotFile"] == depotPath:
>> +            if entry["depotFile"].find(depotPath) >= 0:
>>
>> Does this mean that if 'p4 where' produces multiple lines of output that
>> this will get confused, as it's just going to search for an instance of
>> depotPath.
>
> The reason why I introduced that was because in the test case I implemented (and
> which reflects a scenario I am confronted with in my workplace) the branches
> have a base directory that is removed in the client view mapping.
> As such, we will have a situation where depotPath is //depot/branch1/ while
> runninng "p4 where" will result in //depot/branch1/base/. To overcome this I
> used find() instead of a direct comparison. Now that I think about that, I could
> probably have used the simpler `if depotPath in entry["depotFile"]`...

Hmph, is this find() under discussion the string.find() that finds a
substring?  You are doing >=0 comparison here, but with your example
that entry["depotFile"] may have "base/" appended to what you
expect, the result of running string.find() must yield "0", i.e. no
extra prefix string, no?  I kind of find it hard to believe that it
is OK to have any extra prefix is fine ...

>> The example in the Perforce man page for 'p4 where' would trigger this
>> for example:
>>
>> http://www.perforce.com/perforce/r14.2/manuals/cmdref/p4_where.html
>>
>> -//a/b/file.txt //client/a/b/file.txt //home/user/root/a/b/file.txt
>> //a/b/file.txt //client/b/file.txt /home/user/root/b/file.txt
>
> These are examples where a simple comparison as was implemented would work.

... so is this "find()" an attempt to catch prefix like "-"?  Even
if it that were the reason why you do not limit the acceptable
return value from find() to zero, it feels a bit too loose to allow
anything if the only thing you want to allow is a single "-" prefix.

Can you explain this a bit better?  I cannot quite tell what is
going on from what was written in the log message.

>> As an experiment, I hacked git-p4 to always use p4Where rather than
>> getClientRoot(), which I would have thought ought to work, but while
>> most of the tests passed, Pete's client-spec torture tests failed.
>
> That was exactly my first approach and got to the same conclusion. I would have
> investigated it further but since I haven't had much free time to invest in
> solving this problem I decided to implement an intermediary solution that would
> not introduce any regressions.

Thanks.

  reply	other threads:[~2015-04-13  3:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-28 12:28 [PATCH 0/2] git-p4: Improve client path detection Vitor Antunes
2015-03-28 12:28 ` [PATCH 1/2] git-p4: Check branch detection and client view together Vitor Antunes
2015-03-28 12:28 ` [PATCH 2/2] git-p4: Improve client path detection when branches are used Vitor Antunes
2015-03-29 23:31 ` [PATCH] t9814: Guarantee only one source exists in git-p4 copy tests Vitor Antunes
2015-03-30  3:03   ` Junio C Hamano
2015-03-31 13:26     ` Luke Diamand
2015-03-31 23:29     ` [PATCH V2] " Vitor Antunes
2015-04-04  8:31     ` [PATCH] " Luke Diamand
2015-04-04 19:41       ` Junio C Hamano
2015-04-05 23:08         ` [PATCH V3] " Vitor Antunes
2015-04-05 19:27 ` [PATCH 0/2] git-p4: Improve client path detection Luke Diamand
2015-04-05 22:57   ` Vitor Antunes
2015-04-13  3:40     ` Junio C Hamano [this message]
2015-04-18 22:40       ` Vitor Antunes
2015-04-18 23:24       ` [PATCH] git-p4: Improve client path detection when branches are used Vitor Antunes
2015-04-19  0:58         ` Junio C Hamano
2015-04-19 10:59           ` Vitor Antunes
2015-04-20  5:32             ` Junio C Hamano

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=xmqqsic44rw5.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=luke@diamand.org \
    --cc=vitor.hda@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.