Re: Git p4 sync changelist interval
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 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
On 6 June 2017 at 08:00, Luke Diamandwrote: > 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
On 6 June 2017 at 00:29, Luke Diamandwrote: > 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
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
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