Re: Git p4 sync changelist interval

2017-06-06 Thread Luke Diamand
On 6 June 2017 at 08:56, Андрей Ефанов <1134t...@gmail.com> wrote:
>>
>> It seems to be something to do with the code around line 3395 that says:
>>
>> if self.changeRange == "@all":
>> self.changeRange = ""
>> elif ',' not in self.changeRange:
>>
>> It's finding a lower revision number with which to later call
>> importHeadRevision(), but that only seems to be called if the revision
>> range does *not* have a "," in it. As a result, we never actually call
>> importHeadRevision() and so files end up missing.
>>
>> The obvious fix of fishing out the "@3" from the "@3,5" revision range
>> works in this instance, but breaks some of the regression tests.
>>
>> Luke
>
> I did the same change before and it worked for me. I'd like to find
> out if it is a bug (I think it is), a normal behavior or am I doing
> something wrong.
>
> So according to what you say, it is a bug.

It's a bug!

I think you can workaround it by doing:

$ git p4 clone //depot@3
$ git p4 sync

I'll see if I can workout why my obvious fix caused the tests to fail.


Re: Git p4 sync changelist interval

2017-06-06 Thread Андрей Ефанов
2017-06-06 10:49 GMT+03:00 Luke Diamand :
> On 6 June 2017 at 08:00, Luke Diamand  wrote:
>> On 6 June 2017 at 00:29, Luke Diamand  wrote:
>>> On 5 June 2017 at 19:50, Андрей Ефанов <1134t...@gmail.com> wrote:
 2017-06-04 14:09 GMT+03:00 Luke Diamand :
>
>
> >
> > The problem, as I see it, is that before syncing changes in the given
> > range, p4 task does not sync to cl1 version of the repo, and applies
> > commits to the empty repository.
> > Is it a bug or my misunderstanding of how git p4 should work?
>
> Possibly I'm misunderstanding what you're doing! Can you give a
> sequence of steps to show the problem?

 What I meant is:

 1. Create p4 depot
 2. Add first.file (CL 2)
 3. Add second.file (at CL 3)
 4. Add third.file (at CL 4)
 5. Modify first.file (at CL 5)
 4. git-p4 clone //depot@3,5

 In this case first.file, will not be represented in the repository.
>>>
>>> Hmmm, it's not working right for me. Although in my case I seem to be
>>> missing the second file.
>>>
>>> It's fine if I don't use the revision range "3,5".
>>
>> It's also fine if I do:
>>
>> git p4 sync //depot@3
>> cd depot
>> git p4 rebase
>
> It seems to be something to do with the code around line 3395 that says:
>
> if self.changeRange == "@all":
> self.changeRange = ""
> elif ',' not in self.changeRange:
>
> It's finding a lower revision number with which to later call
> importHeadRevision(), but that only seems to be called if the revision
> range does *not* have a "," in it. As a result, we never actually call
> importHeadRevision() and so files end up missing.
>
> The obvious fix of fishing out the "@3" from the "@3,5" revision range
> works in this instance, but breaks some of the regression tests.
>
> Luke

I did the same change before and it worked for me. I'd like to find
out if it is a bug (I think it is), a normal behavior or am I doing
something wrong.

So according to what you say, it is a bug.

Andrew


Re: Git p4 sync changelist interval

2017-06-06 Thread Luke Diamand
On 6 June 2017 at 08:00, Luke Diamand  wrote:
> On 6 June 2017 at 00:29, Luke Diamand  wrote:
>> On 5 June 2017 at 19:50, Андрей Ефанов <1134t...@gmail.com> wrote:
>>> 2017-06-04 14:09 GMT+03:00 Luke Diamand :


 >
 > The problem, as I see it, is that before syncing changes in the given
 > range, p4 task does not sync to cl1 version of the repo, and applies
 > commits to the empty repository.
 > Is it a bug or my misunderstanding of how git p4 should work?

 Possibly I'm misunderstanding what you're doing! Can you give a
 sequence of steps to show the problem?
>>>
>>> What I meant is:
>>>
>>> 1. Create p4 depot
>>> 2. Add first.file (CL 2)
>>> 3. Add second.file (at CL 3)
>>> 4. Add third.file (at CL 4)
>>> 5. Modify first.file (at CL 5)
>>> 4. git-p4 clone //depot@3,5
>>>
>>> In this case first.file, will not be represented in the repository.
>>
>> Hmmm, it's not working right for me. Although in my case I seem to be
>> missing the second file.
>>
>> It's fine if I don't use the revision range "3,5".
>
> It's also fine if I do:
>
> git p4 sync //depot@3
> cd depot
> git p4 rebase

It seems to be something to do with the code around line 3395 that says:

if self.changeRange == "@all":
self.changeRange = ""
elif ',' not in self.changeRange:

It's finding a lower revision number with which to later call
importHeadRevision(), but that only seems to be called if the revision
range does *not* have a "," in it. As a result, we never actually call
importHeadRevision() and so files end up missing.

The obvious fix of fishing out the "@3" from the "@3,5" revision range
works in this instance, but breaks some of the regression tests.

Luke


Re: Git p4 sync changelist interval

2017-06-06 Thread Luke Diamand
On 6 June 2017 at 00:29, Luke Diamand  wrote:
> On 5 June 2017 at 19:50, Андрей Ефанов <1134t...@gmail.com> wrote:
>> 2017-06-04 14:09 GMT+03:00 Luke Diamand :
>>>
>>>
>>> >
>>> > The problem, as I see it, is that before syncing changes in the given
>>> > range, p4 task does not sync to cl1 version of the repo, and applies
>>> > commits to the empty repository.
>>> > Is it a bug or my misunderstanding of how git p4 should work?
>>>
>>> Possibly I'm misunderstanding what you're doing! Can you give a
>>> sequence of steps to show the problem?
>>
>> What I meant is:
>>
>> 1. Create p4 depot
>> 2. Add first.file (CL 2)
>> 3. Add second.file (at CL 3)
>> 4. Add third.file (at CL 4)
>> 5. Modify first.file (at CL 5)
>> 4. git-p4 clone //depot@3,5
>>
>> In this case first.file, will not be represented in the repository.
>
> Hmmm, it's not working right for me. Although in my case I seem to be
> missing the second file.
>
> It's fine if I don't use the revision range "3,5".

It's also fine if I do:

git p4 sync //depot@3
cd depot
git p4 rebase


Re: Git p4 sync changelist interval

2017-06-05 Thread Luke Diamand
On 5 June 2017 at 19:50, Андрей Ефанов <1134t...@gmail.com> wrote:
> 2017-06-04 14:09 GMT+03:00 Luke Diamand :
>>
>> On 4 June 2017 at 10:56, Андрей Ефанов <1134t...@gmail.com> wrote:
>> > Hello,
>> >
>> > My goal is to sync the repository from p4 using an interval of
>> > changelists so that the first changelist version of the repository
>> > would be considered as an initial commit.
>> > So I used the following command:
>> >
>> >  git p4 clone //depot@cl1,cl2
>> >
>> > And when it finished, the files, that were created before the cl1 were
>> > not in the HEAD.
>>
>> Do you mean that if foo.c was created at cl1+1, that after doing the
>> clone, it wasn't there?
>>
>> If so, that doesn't sound right to me.
>>
>> I have just tried doing what I think you mean:
>>
>> 1. Create p4 depot
>> 2. Add foo.c (at CL 2)
>> 3. Add bar.c (at CL 3)
>> 4. git-p4 clone //depot@2,3
>>
>> I end up with both files.
>>
>> >
>> > The problem, as I see it, is that before syncing changes in the given
>> > range, p4 task does not sync to cl1 version of the repo, and applies
>> > commits to the empty repository.
>> > Is it a bug or my misunderstanding of how git p4 should work?
>>
>> Possibly I'm misunderstanding what you're doing! Can you give a
>> sequence of steps to show the problem?
>
> What I meant is:
>
> 1. Create p4 depot
> 2. Add first.file (CL 2)
> 3. Add second.file (at CL 3)
> 4. Add third.file (at CL 4)
> 5. Modify first.file (at CL 5)
> 4. git-p4 clone //depot@3,5
>
> In this case first.file, will not be represented in the repository.

Hmmm, it's not working right for me. Although in my case I seem to be
missing the second file.

It's fine if I don't use the revision range "3,5".

Luke


Re: Git p4 sync changelist interval

2017-06-04 Thread Luke Diamand
On 4 June 2017 at 10:56, Андрей Ефанов <1134t...@gmail.com> wrote:
> Hello,
>
> My goal is to sync the repository from p4 using an interval of
> changelists so that the first changelist version of the repository
> would be considered as an initial commit.
> So I used the following command:
>
>  git p4 clone //depot@cl1,cl2
>
> And when it finished, the files, that were created before the cl1 were
> not in the HEAD.

Do you mean that if foo.c was created at cl1+1, that after doing the
clone, it wasn't there?

If so, that doesn't sound right to me.

I have just tried doing what I think you mean:

1. Create p4 depot
2. Add foo.c (at CL 2)
3. Add bar.c (at CL 3)
4. git-p4 clone //depot@2,3

I end up with both files.

>
> The problem, as I see it, is that before syncing changes in the given
> range, p4 task does not sync to cl1 version of the repo, and applies
> commits to the empty repository.
> Is it a bug or my misunderstanding of how git p4 should work?

Possibly I'm misunderstanding what you're doing! Can you give a
sequence of steps to show the problem?

Thanks!
Luke