FAQ
l1:/pro/3gl/CPAN 193 > p4 sedit perl/Configure
//depot/perl/Configure#550 - updating /pro/3gl/CPAN/perl/Configure
//depot/perl/Configure#550 - opened for edit
... //depot/perl/Configure - also opened by jhi@kosh


Uhhh, and next?

--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0, & 5.9.x, and 806 on HP-UX 10.20 & 11.00, 11i,
AIX 4.3, SuSE 8.2, and Win2k. http://www.cmve.net/~merijn/
http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org

Search Discussions

  • Pprymmer at Nov 12, 2003 at 4:41 pm
    After two people have p4 edit'ed the same revision of a file
    there are at least two possible usage scenarios:

    0). One of you issues 'p4 revert perl/Configure' and waits for the other to
    submit
    their change. After that the other person can issue 'p4 sync
    perl/Configure' and
    sync out the submitted change and can then continue (i.e. issue p4 edit and
    p4 submit).
    This method serializes the changes made to the file.

    1). Neither of you reverts the file and one submits. When the second
    person goes
    to submit their changelist it will be marked as 'pending' rather than
    submitted and
    won't go into the depot until after a p4 resolve is done to merge and/or
    edit the changes.
    This method allows for merging concurrent changes (note that the merge
    utility embeded
    within the p4 resolve command is not unlike RCS merge and can leave lines
    with
    '>>>' and '<<<' merge conflict markers within a source files if you are not
    careful with the
    'am' command (e.g. you and Jarkko both changed the very same line in the
    file)).

    I hope that helps.

    Peter Prymmer

    "H.Merijn Brand" <h.m.brand@hccnet.nl> wrote on 11/12/2003 10:59:34 AM:
    l1:/pro/3gl/CPAN 193 > p4 sedit perl/Configure
    //depot/perl/Configure#550 - updating /pro/3gl/CPAN/perl/Configure
    //depot/perl/Configure#550 - opened for edit
    ... //depot/perl/Configure - also opened by jhi@kosh


    Uhhh, and next?

    --
    H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
    using perl-5.6.1, 5.8.0, & 5.9.x, and 806 on HP-UX 10.20 & 11.00, 11i,
    AIX 4.3, SuSE 8.2, and Win2k. http://www.cmve.net/~merijn/
    http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
    send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org
  • H.Merijn Brand at Nov 12, 2003 at 4:48 pm

    On Wed 12 Nov 2003 17:41, PPrymmer@factset.com wrote:




    After two people have p4 edit'ed the same revision of a file
    there are at least two possible usage scenarios:

    0). One of you issues 'p4 revert perl/Configure' and waits for the other to
    submit their change. After that the other person can issue 'p4 sync
    perl/Configure' and sync out the submitted change and can then continue
    (i.e. issue p4 edit and p4 submit).
    This method serializes the changes made to the file.
    This is what I did
    1). Neither of you reverts the file and one submits. When the second
    person goes to submit their changelist it will be marked as 'pending'
    rather than submitted and won't go into the depot until after a
    p4 resolve is done to merge and/or edit the changes.
    This method allows for merging concurrent changes (note that the merge
    utility embeded within the p4 resolve command is not unlike RCS merge
    and can leave lines with '>>>' and '<<<' merge conflict markers within
    a source files if you are not careful with the 'am' command (e.g. you
    and Jarkko both changed the very same line in the file)).

    I hope that helps.
    Yes and no.

    Yes, since 0) is what I did, I now know I did the right thing
    No, I did get no respons to the patch announcement, from not even one person
    on the Cc list, so either
    - nobody cares
    - all agree
    - nobody understands

    Now I'd just like to know what Jarkko is changing, so I could maybe anticipate
    on that. Let's just hope he did not accidently leave a dangling open p4 edit

    Peter Prymmer

    "H.Merijn Brand" <h.m.brand@hccnet.nl> wrote on 11/12/2003 10:59:34 AM:
    l1:/pro/3gl/CPAN 193 > p4 sedit perl/Configure
    //depot/perl/Configure#550 - updating /pro/3gl/CPAN/perl/Configure
    //depot/perl/Configure#550 - opened for edit
    ... //depot/perl/Configure - also opened by jhi@kosh


    Uhhh, and next?
    --
    H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
    using perl-5.6.1, 5.8.0, & 5.9.x, and 806 on HP-UX 10.20 & 11.00, 11i,
    AIX 4.3, SuSE 8.2, and Win2k. http://www.cmve.net/~merijn/
    http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
    send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org
  • Jarkko Hietaniemi at Nov 12, 2003 at 5:10 pm

    Now I'd just like to know what Jarkko is changing, so I could maybe anticipate
    on that. Let's just hope he did not accidently leave a dangling open p4 edit
    It's probably a dangling p4 edit but feel free to go ahead and ignore it;
    I have no open projects. If I ever return I'll just p4 revert.

    --
    Jarkko Hietaniemi <jhi@iki.fi> http://www.iki.fi/jhi/ "There is this special
    biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
  • Pprymmer at Nov 12, 2003 at 5:44 pm

    <h.m.brand@hccnet.nl> wrote on 11/12/2003 11:47:13 AM:

    I hope that helps.
    Yes and no.

    Yes, since 0) is what I did, I now know I did the right thing
    Jarkko's reply would indicate that it is OK for you to proceed
    with a p4 edit and a p4 submit. For his part Jarkko might try to
    issue p4 revert sooner rather than later (if necessary preceeded
    by an appropriate setting of $P4CLIENT for the environment).
    No, I did get no respons to the patch announcement, from not even one person
    on the Cc list, so either
    - nobody cares
    - all agree
    - nobody understands

    Now I'd just like to know what Jarkko is changing, so I could maybe
    anticipate
    on that. Let's just hope he did not accidently leave a dangling open p4
    edit

    Apparently he did. Since your comment solicitation was so nicely worded
    allow me to proceed with my own remarks for your consideration. I presume
    you wanted commentary on the new *.cbu file patch (please correct if I am
    wrong about that). Among other things I noted that it seemed to introduce
    new filenames such as for example:
    if $test -f uselargefiles.cbu; then
    echo "Your platform has some specific hints regarding large file
    builds, using them..."
    . ./uselargefiles.cbu
    fi
    If I recall correctly Configure still needs to be able to run
    under the port of bash to djgpp on MS-DOS and/or PC-DOS which
    still have the 8.3 file naming limitation. I guess
    that I would recommend shortening long CBU file names such as
    uselargefiles.cbu, uselongdouble.cbu, etc. so that such call
    back units might be used on platforms with odd filename limitations.
    Admittedly it is unlikely that large files or long doubles will
    be in the C implementations on djgpp, hence the test -f can
    safely bypass those two examples on djgpp. But I think you
    are trying to set a precedent with the *.cbu files and you
    might want to be mindful of the limitations imposed on odd
    platforms such as djgpp on DOS.

    Peter Prymmer
  • H.Merijn Brand at Nov 12, 2003 at 8:51 pm

    On Wed 12 Nov 2003 18:43, PPrymmer@factset.com wrote:
    <h.m.brand@hccnet.nl> wrote on 11/12/2003 11:47:13 AM:
    I hope that helps.
    Yes and no.

    Yes, since 0) is what I did, I now know I did the right thing
    Jarkko's reply would indicate that it is OK for you to proceed
    with a p4 edit and a p4 submit. For his part Jarkko might try to
    issue p4 revert sooner rather than later (if necessary preceeded
    by an appropriate setting of $P4CLIENT for the environment).
    I will prceed :)
    No, I did get no respons to the patch announcement, from not even one
    person on the Cc list, so either
    - nobody cares
    - all agree
    - nobody understands

    Now I'd just like to know what Jarkko is changing, so I could maybe
    anticipate on that. Let's just hope he did not accidently leave a
    dangling open p4 edit
    Apparently he did. Since your comment solicitation was so nicely worded
    allow me to proceed with my own remarks for your consideration. I presume
    you wanted commentary on the new *.cbu file patch (please correct if I am
    wrong about that).
    Actually on all three points, but I'm happy with every feedback.
    Among other things I noted that it seemed to introduce
    new filenames such as for example:
    No, it just *moves* some code. No new code is involved, no new filenames are
    involved. What this patch changes (it has already been changed in the
    metaunits, but that should promote to Configure), is that the already
    supported call-back units will now be called whatever the variable they
    control is set to. Before the patch, the call-back was only called if the
    variable was set.
    if $test -f uselargefiles.cbu; then
    echo "Your platform has some specific hints regarding large file builds, using them..."
    . ./uselargefiles.cbu
    fi
    If I recall correctly Configure still needs to be able to run
    under the port of bash to djgpp on MS-DOS and/or PC-DOS which
    still have the 8.3 file naming limitation. I guess
    that I would recommend shortening long CBU file names such as
    uselargefiles.cbu, uselongdouble.cbu, etc. so that such call
    back units might be used on platforms with odd filename limitations.
    Admittedly it is unlikely that large files or long doubles will
    be in the C implementations on djgpp, hence the test -f can
    safely bypass those two examples on djgpp. But I think you
    are trying to set a precedent with the *.cbu files and you
    might want to be mindful of the limitations imposed on odd
    platforms such as djgpp on DOS.
    Though your argument is perfect, and you are right, it is probably a lot more
    work to change this back. I will put this on my todo list to investigate. A
    new problem might arise in backporting this to 5.6.2 and 5.8.0, whereas the
    current approach will work as expected. Looking at the state of the hint files
    that we have (and IIRC Raphael just blindly copied them back to 5.6.2) this
    will be completely safe. Even the patch that will be made to the newly
    generated Configure might be easy to apply to 5.6.2 and 5.8.3
    Peter Prymmer
    Thanks for making me feel not alone :)

    To summarize, if I've done things *right*, nobody will ever notice the changes.
    I've only opened doors to new hint possibilities in the future :)

    --
    H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
    using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
    WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: smokers@perl.org
    http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
    send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-build @
categoriesperl
postedNov 12, '03 at 4:00p
activeNov 12, '03 at 8:51p
posts6
users3
websiteperl.org

People

Translate

site design / logo © 2019 Grokbase