Results 1 to 10 of 10

Thread: 18481: Revert unintended .classpath and .project changes from 18480, sorry I haven't

  1. #1
    Feed Reader RSS Bot's Avatar
    Join Date
    Jul 2009
    Posts
    11,528

    RSS 18481: Revert unintended .classpath and .project changes from 18480, sorry I haven't

    Revert unintended .classpath and .project changes from 18480, sorry I haven't committed in a while!

    by kirchoffjosephp on 2018-02-28 01:52:41

    M /.classpath (view) (diff)
    M /.project (view) (diff)
    Download the latest KolMafia build here.
    Every new revision posted within the hour.
    New EXE builds every Monday.

  2. #2
    Senior Member AlbinoRhino's Avatar
    Join Date
    May 2008
    Posts
    876

    Default

    The changes to these files in r18480 appear to bork svn updating, making it impossible to reach the corrections in this revision.

    Seems to error out with: Invalid diff stream: [tgt] insn 0 starts beyond the target view position

    Occasionally, I am getting an error about the checksum for .classpath not matching, instead.

    Maybe there is some svn trick I'm unaware of to get past the r18480 revision ? Or maybe these 2 commits can be deleted by someone with the appropriate access ? Not sure how all that works.

    Edit: Looks like the 'Daily Builds' are broke with the same error.
    Last edited by AlbinoRhino; 02-28-2018 at 08:17 AM.

  3. #3
    Developer
    Join Date
    Apr 2010
    Posts
    4,950

    Default

    I get same error too

  4. #4
    Developer fronobulax's Avatar
    Join Date
    Feb 2009
    Location
    Central Virginia, USA
    Posts
    4,204

    Default

    Might be resolved. I deleted the files, checked in, and then added the files and just had a good build. If someone is motivated it might be worth checking what is there now with what was where before the hiccup to make sure I didn't introduce anything.

  5. #5
    Senior Member AlbinoRhino's Avatar
    Join Date
    May 2008
    Posts
    876

    Default

    Just built and logged in with 18483. All appears normal (except prices not updating). Thanks frono !!

  6. #6
    Developer fronobulax's Avatar
    Join Date
    Feb 2009
    Location
    Central Virginia, USA
    Posts
    4,204

    Default

    Just built and logged in with 18483. All appears normal (except prices not updating). Thanks frono !!
    Originally Posted by AlbinoRhino View Post
    My experience as well, and you're welcome. In the Days of My Youth I often had official or de facto configuration management responsibilities and I had to maintain and manage my own repositories. Some techniques still apply :-)

    The prices still do not update and we have no feedback yet as to whether the version from ci.kolmafia.us works or differs from local builds.
    You just vehemently agreed with me
    Originally Posted by Veracity View Post
    I agree with frono.
    Originally Posted by Veracity View Post

  7. #7
    Senior Member AlbinoRhino's Avatar
    Join Date
    May 2008
    Posts
    876

    Default

    Yeah, pretty sure the prices issue was pre-existing and unrelated.

    When I was messing with this, I tried an update with these 2 files excluded. I was able to get the current revision (according to Tortoise) and build mafia but mafia thought it was at revision 0. So, any script with a "since" statement refused to run. But, I thought it was interesting that mafia still works even when all version information is lost. Not really sure what .classpath & .project do. I do understand what an environment path is so I suspect 'classpath' is something similar. So, .project is maybe related to versioning somehow ?

    In any event, I am just rambling about nothing ! Thanks again.

  8. #8
    Developer fronobulax's Avatar
    Join Date
    Feb 2009
    Location
    Central Virginia, USA
    Posts
    4,204

    Default

    Speaking from memory, not knowledge.

    The mafia build process extracts version info from SVN and inserts it as a string constant in a source file (KoLmafiaConstants?) before compiling. If the build process fails to do that then the string is empty. The version information is pretty much only used for since and display to the user, so its absence won't break too many things.

    If teh build process fails at the wrong time, it leaves behind a modified file which a SVN update will not overwrite. When I see a build name with an M appended and I didn't think I had any local changes, that's usually the culprit.
    You just vehemently agreed with me
    Originally Posted by Veracity View Post
    I agree with frono.
    Originally Posted by Veracity View Post

  9. #9
    Senior Member AlbinoRhino's Avatar
    Join Date
    May 2008
    Posts
    876

    Default

    Oh yea...that was the other thing I noticed. Instead of the usual "M" after the revision #, ant had "MP".

  10. #10
    Developer
    Join Date
    Apr 2006
    Posts
    926

    Default

    Yeah sorry about that, it appears something went wrong on SourceForge's end when I committed this and made updating to this revision impossible.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •