Indeed



  • A quickie before the weekend: I just looked at the latest submission in source control. The commit message is "flash file updated". The commit consists of a single flash file that apparently has been updated.



  • @DOA said:

    A quickie before the weekend: I just looked at the latest submission in source control. The commit message is "flash file updated". The commit consists of a single flash file that apparently has been updated.

     

    The only way that could be more hilariously wrong is if you did a diff and found that it was exactly the same as the previous version.



  • @Someone You Know said:

    @DOA said:

    A quickie before the weekend: I just looked at the latest submission in source control. The commit message is "flash file updated". The commit consists of a single flash file that apparently has been updated.

     

    The only way that could be more hilariously wrong is if you did a diff and found that it was exactly the same as the previous version.

    No, it could also be hilariously wrong if he downloaded the file and found it was really a .gif with whatever extension Flash uses.



  • @DOA said:

    The commit message is "flash file updated". The commit consists of a single flash file that apparently has been updated.

    So the comment in the log is correct. Where's the problem? It's nice to see it in the log and not to have to look in every Revision that is uncommented...



  • @Grevas said:

    @DOA said:

    The commit message is "flash file updated". The commit consists of a single flash file that apparently has been updated.

    So the comment in the log is correct. Where's the problem? It's nice to see it in the log and not to have to look in every Revision that is uncommented...

    If it's an .as file you can probably tell what changed from the diff. (Although you still don't know why.)

    If it's a .swf file, you're up shit creek with no paddle. You don't know what changed, *and* you don't know why it changed.



  • @blakeyrat said:

    If it's an .as file you can probably tell what changed from the diff. (Although you still don't know why.)

    If it's a .swf file, you're up shit creek with no paddle. You don't know what changed, *and* you don't know why it changed.

    It's a .swf of course. Luckily I don't have anything to do with the UI; I just check the logs for laughs



  • @blakeyrat said:

    @Grevas said:

    @DOA said:

    The commit message is "flash file updated". The commit consists of a single flash file that apparently has been updated.

    So the comment in the log is correct. Where's the problem? It's nice to see it in the log and not to have to look in every Revision that is uncommented...

    If it's an .as file you can probably tell what changed from the diff. (Although you still don't know why.)

    If it's a .swf file, you're up shit creek with no paddle. You don't know what changed, *and* you don't know why it changed.

     

    I really don't understand why you're bagging on this.  A swf is compiled.  It's like saying you think you should be able to look into a dll for .Net or a .class file for java.  However, one nice update for .fla's is that with CS5, you can break everything down into it's elements with an xml descriptor file.  So, when everyone gets around to upgrading and using that feature, you'll be able to see exactly what changed.  It'll no longer be a black box.



  • @Bobrot said:

    @blakeyrat said:

    @Grevas said:

    @DOA said:

    The commit message is "flash file updated". The commit consists of a single flash file that apparently has been updated.

    So the comment in the log is correct. Where's the problem? It's nice to see it in the log and not to have to look in every Revision that is uncommented...

    If it's an .as file you can probably tell what changed from the diff. (Although you still don't know why.)

    If it's a .swf file, you're up shit creek with no paddle. You don't know what changed, *and* you don't know why it changed.

     

    I really don't understand why you're bagging on this.  A swf is compiled.  It's like saying you think you should be able to look into a dll for .Net or a .class file for java.  However, one nice update for .fla's is that with CS5, you can break everything down into it's elements with an xml descriptor file.  So, when everyone gets around to upgrading and using that feature, you'll be able to see exactly what changed.  It'll no longer be a black box.

     

    No no, the point is that the description, while accurate, was completely useless for knowing what about the flash file was updated.



  • @Bobrot said:

    I really don't understand why you're bagging on this.

    I'm not "bagging" on Flash, if that's what you mean. I'm just saying that since .swf files are compiled, there's no way to tell what changed between this version and the last.

    @Bobrot said:

    However, one nice update for .fla's is that with CS5, you can break everything down into it's elements with an xml descriptor file.  So, when everyone gets around to upgrading and using that feature, you'll be able to see exactly what changed.  It'll no longer be a black box.

    Yesss... but we're not talking about .fla files, we're talking about .swf files which, as you pointed out, are compiled.

    I really don't understand why you're bagging on me.



  •  I don't understand. If you're thinking you would be better off by seeing a detailed message about what changed in the flash file, you wouldn't. When someone checks in a binary, you cannot determine anything, regardless of whether their checkin message is (null), meaningless, fradulent, false, or correct.

     Therefore, a meaningless comment that says "checking in" is just as worthwhile to you.



  • This is why nobody should have commit access.



  • We can force that a message is put before doing a Commit. The next step is to create an IA to check if the text really means something before doing the commit.



  • @ericmorton said:

    When someone checks in a binary, you cannot determine anything, regardless of whether their checkin message is (null), meaningless, fradulent, false, or correct.

    Well done, you're on the right track here. So the answer is, don't just check in the binary, but...?
    Or if you cannot do that for whatever reason (external dependency), then what would you do? Remember what the principal goal of source control is.



  • Are people seriously suggesting that "changed background from blue to red in flash file" is no better than "flash file updated"?



    (Assuming some sick requirement to check-in the binary in the first place, that is.)



  • @b-redeker said:

    Well done, you're on the right track here. So the answer is, don't just check in the binary, but...?
    Or if you cannot do that for whatever reason (external dependency), then what would you do? Remember what the principal goal of source control is.

    Open source man! WOOO! Flash is proprietary CANCER and will KILL YOUR PUPPIES, RMS or maybe ESR or maybe JWZ said so. If you can't run it from a teletype 5 timezones away using 2-letter commands like "rm" and "ls," it's proprietary CANCER!



  • @DOA said:

    I just check the logs for laughs



  • @b-redeker said:

    @DOA said:

    I just check the logs for laughs

     

    LOL

    Not this shit again.



  • @Shishire said:

    No no, the point is that the description, while accurate, was completely useless for knowing what about the flash file was updated.
    Did anyone think to check the previous commits for info? Usually when I see this the binary commit's just catching the binary up to the last source revision.



  • @b-redeker said:

    @DOA said:

    I just check the logs for laughs

    That's even less funny than this.



  • @The_Assimilator said:

    @b-redeker said:

    @DOA said:

    I just check the logs for laughs

    That's even less funny than this.

    Oh, and I thought laughing logs are high-larious!



  • @b-redeker said:

    @DOA said:

    I just check the logs for laughs

    I checked the logs and then

     



  • What superjer said.  A detailed message would at least tell you what the coder intended to change, even if they got it wrong.  Unless the coder is actively malicious, in which case you should already be reporting them for treason and/or preparing your own exit plan.

     

    And yes, I've checked in binaries myself (mostly Crystal Reports forms).  Not that I expect to ever run any sort of automated diff on them, but at least they're available for manual inspection should the need arise.

     


Log in to reply