• (disco) in reply to Steve_The_Cynic

    We still use VSS 6.0, and one of our databases is over 40GB! It is a small team, so checkout collisions are few and far between. One thing we have learned -- do NOT rebuild names.dat if you use long filenames. Well, unless you feel like renaming every file afterwards.

  • (disco) in reply to pcxt_
    pcxt_:
    We still use VSS 6.0
    :mask:
    pcxt_:
    It is a small team
    Then switch already! ;)
  • (disco)

    I'd just tell them we can set "needs-lock" for everything and call it a day.

    It's difficult to presuade people who don't trust automatic merge that it can be done.

  • (disco) in reply to Steve_The_Cynic
    Steve_The_Cynic:
    VSS had(1) some epic issues

    As someone who checked in code to a VSS repository 2 days ago, I'm not sure if I find your use of past tense amusing or depressing

  • (disco) in reply to CoyneTheDup

    If you never inflict (or push, if you want to be particularly boring about terms I suppose), then you've got the same problem as if someone never committed in any VCS where they're the same action. Or the same problem as if someone was working on a branch that they never merged back in.

  • (disco) in reply to boomzilla

    And, clearly, failing to properly separate "commit" and "inflict" leads to "conflict".

  • (disco) in reply to Watson

    Don't rebase me bro!

  • (disco) in reply to FrostCat
    FrostCat:
    When you say shelving, are you talking about those old-fashioned German toilets with an actual shelf on them so you can inspect your crap for worms?

    I think in this analogy shelving is any sort of receptacle for bringing back everything you brought with you on a hiking trip. You keep the results to flush at a later point, perhaps having added to them.

  • (disco) in reply to Shoreline

    Is anyone lese concerned about the metaphorical comparison of his code with what he produces in the bathroom stall?

  • (disco)

    SVN does support locking files so that no one else can lock the file or commit it until the lock is released. TortoiseSVN supports this as well, and will indicate the locked status in the icon overlay.

  • (disco)

    This is what happens when you force changes on people who are not ready for them.

  • (disco) in reply to immibis_

    But will they ever be ready? Meanwhile VSS is a risk for your code history when it inevitably grows corrupt.

  • (disco) in reply to JBert
    JBert:
    Meanwhile VSS is risking your code

    FTFY. And yes, I still have to use it. It's ok though, I have a git backup.

  • (disco) in reply to JBert
    JBert:
    But will they ever be ready?

    They'll eventually retire or die, so yes.

  • (disco) in reply to TheCPUWizard
    TheCPUWizard:
    If it doesn't, then you are "Doing it Wrong".
    Up to a point. If the affected code is in a platform-specific section that won't run on the build machines, then automated unit testing might be, um, difficult on the build machines. Of course, that might mean you've done something wrong...
  • (disco) in reply to Jaloopa
    Jaloopa:
    As someone who checked in code to a VSS repository 2 days ago, I'm not sure if I find your use of past tense amusing or depressing
    That part of my statement was expressing, er, hope...
  • (disco) in reply to dkf
    dkf:
    They'll eventually retire or die, so yes.
    So they'll either become irrelevant or be in a better place but they'll *still* not be ready, it's just that they can no longer stop it.
  • (disco) in reply to Steve_The_Cynic
    Steve_The_Cynic:
    If the affected code is in a platform-specific section that won't run on the build machines

    This is why "good" build systems have the ability to execute code in a Lab environment when appropriate.

    Trivial example: I am developing applications that run on both Linux and Windows platforms. As part of a "validation build" (not a CI build) the code gets deployed to many machines (different versions, configurations, etc.)

    Disclaimer: I have forgotten the exact context of this part of the discussion and am too lazy to scroll back and find it....

  • (disco) in reply to TheCPUWizard
    TheCPUWizard:
    This is why "good" build systems have the ability to execute code in a Lab environment when appropriate.

    Trivial example: I am developing applications that run on both Linux and Windows platforms. As part of a "validation build" (not a CI build) the code gets deployed to many machines (different versions, configurations, etc.)

    Disclaimer: I have forgotten the exact context of this part of the discussion and am too lazy to scroll back and find it....

    (Context reminder: Automated Unit Testing in builds)

    The sort of thing I'm thinking of is units for kernel-mode shit that won't run in user-mode programs without superheavy frameworking (i.e. sources of test-harness bugs). If the kernel-mode shit needs to be compiled in rather than loaded in a module, then to run automated unit tests, you have to force an update, reboot, and see what happens. And cope gracefully on the build machine if the code is bad and the test machine doesn't reboot properly.

  • (disco) in reply to Steve_The_Cynic
    Steve_The_Cynic:
    The sort of thing I'm thinking of is units for kernel-mode shit that won't run in user-mode programs without superheavy frameworking (i.e. sources of test-harness bugs). If the kernel-mode shit needs to be compiled in rather than loaded in a module, then to run automated unit tests, you have to force an update, reboot, and see what happens. And cope gracefully on the build machine if the code is bad and the test machine doesn't reboot properly.
    Sounds like a job for virtualization...
  • (disco) in reply to tarunik
    tarunik:
    Sounds like a job for virtualization...
    Up to a point, but I never said the test machine has to be real hardware. However, if the real hardware has specialist devices that aren't present in your VM environment of choice, like e.g. crypto modules or ARM CPUs, the cunning plan to run the test machine in a VM or emulator won't work so well.

    And that doesn't solve the problem of how the AUT procedure in the build copes with a borked test machine.

    And really, such a thing (real hardware, virtualised, or emulated) is a heavy-weight solution to the problem of unit testing a piece of platform-specific code.

  • (disco) in reply to Steve_The_Cynic
    Steve_The_Cynic:
    kernel-mode code that won't run in user-mode programs

    I did conflate two topics....

    1. Automated Integration Testing of things that have hardware/kernel/etc type dependencies. This is where I covered the ability of modern build systems to interact with a "lab". I have set up systems where part of the build includes flashing the bios of a target, loading an O/S, then user-mode code, and finally running tests.

    2. Unit Testing of similar things...

    In this case, the code can (which does not imply should) be refactored. Consider the following as a mental exercise:

    a) Rework code so that every unit (method, function) takes all inputs as parameters, along with all dependencies (i.e. lambdas, function pointers) being passed so that the code does not directly call anything.

    b) Rework parameters such that they are minimal. Use interfaces or values instead of classes

    At this point the individual methods are 100% testable and have no inherent dependencies. Anything specific to the target (.e.g. kernel calls) have been abstracted out of the code and can be replaced for testing purposes.

  • (disco) in reply to TheCPUWizard

    Yes, I know how it's done. All that hides in my remark about "superheavy frameworks". There's a lot of work there to be able to unit test kernel-mode startup / etc. code, and it doesn't help test e.g. device drivers that can only be run in the real kernel (or, again, with superheavy mock-environment).

    My basic assertion is that not everything can be unit tested in a fully automated way, or not at a reasonable cost.

  • (disco) in reply to boomzilla
    boomzilla:
    SVN is terrible because it has the merge-then-commit paradigm. IOW, if someone else committed a change to a file you're working on, you have to update first to get their changes. Which can indeed clobber your code.
    (How) Does this differ from rebasing?
  • (disco) in reply to urkerab
    urkerab:
    (How) Does this differ from rebasing?

    I don't git, but from my understanding, the rebase happens from something committed in the repo, doesn't it? Not a bunch of unstaged changes.

  • (disco)

    Source History Information Tool. Nice acronym. heh heh

  • (disco) in reply to boomzilla
    boomzilla:
    I don't git, but from my understanding, the rebase happens from something committed in the repo, doesn't it? Not a bunch of unstaged changes.
    I don't either... my understanding was that it replaces* your commit with a commit of what it thinks the merge result should be, but has no particular reason to get the merge correct.

    *Ways and means exist to extract the original commit.

  • (disco) in reply to urkerab

    I guess we can wait for a gitter to explain, but at least you know what you're getting into at that point.

  • (disco) in reply to boomzilla
    boomzilla:
    gitter

    http://www.oldskoolman.de/foto-filter/tut/kaefig/gitter-gross.jpg

  • (disco) in reply to aliceif

    Yes but which one? and can we trust it? Setting my trust levels parameter to level 'orange' or 'keen awareness of surroundings'.

    Hmm. Now my trust levels are barking up a storm.

    I know! I will set a flag to silence the barking before the instance occurs, and reroute barking to my email account.

    Hmmm...Spam...I know!!! Inside my email I will set a filter to auto-delete 'trust-bark' emails as they come in.

    There! I took care of everything.

  • (disco) in reply to aliceif
    aliceif:
    http://www.oldskoolman.de/foto-filter/tut/kaefig/gitter-gross.jpg

    I don't "git" it.

  • (disco) in reply to urkerab
    urkerab:
    Ways and means exist to extract the original commit.

    Until you purge the repository. It's the purge (which really deletes things, instead of just marking them as hidden) that worries me as it actively destroys history.

  • (disco) in reply to Shoreline

    "Nononono. We have stalls so one person isn't blocking the whole bathroom with his exclusive access."

  • (disco) in reply to Steve_The_Cynic
    Steve_The_Cynic:
    My basic assertion is that not everything can be unit tested in a fully automated way, or not at a reasonable cost.

    If you look at 100% then I will agree. But I remain confident that the code could be structured so that 95%++ of the code could be tested at minimal cost - which is radically different than "this is a device driver I can't unit test it"

  • (disco) in reply to TheCPUWizard
    TheCPUWizard:
    could be tested

    If you mean run a piece of code that claims to test it, sure. That actually test it, especially when it is code that is doing integration of a bunch of other components?

  • (disco) in reply to dkf
    dkf:
    If you mean run a piece of code that claims to test it, sure.

    I mean what I say and I say what I mean (at least that is always the intent, but I am not infallible)....

    Look at it this way. A given method/function/etc. has a starting address and ending address in memory. "Testing the code" for that method (at the unit level) means testing the specific instructions that are between those two bounds. Everything outside of that is outside the scope of a unit test.

    Code can be structured so that all of the lowest level (e.g. that which directly interacts with the kernel) is written inside of wrapper routines. The rest of the code calls these wrappers exclusively. Now all of the code, except the wrappers can be 100% tested (at the unit level) simply be having a different implementation of the wrappers.

  • (disco)

    What's that sukkah doing there though? This article is dated 30th April. It would be like having a Christmas tree in a topic posted in June.

  • (disco) in reply to Cbuttius
    Cbuttius:
    What's that sukkah doing there though? This article is dated 30th April. It would be like having a Christmas tree in a topic posted in June.
    According to Wikimedia (the source of the image), it's a Stringy-bark dunny (outhouse) in Walcha, NSW, Australia.
  • (disco) in reply to Choonster
    Choonster:
    According to Wikimedia (the source of the image), it's a Stringy-bark dunny (outhouse) in Walcha, NSW, Australia.

    So do Australians normally crap in Jewish religious artifacts?

  • (disco) in reply to boomzilla
    boomzilla:
    So do Australians normally crap in Jewish religious artifacts?
    Probably only the worst of the bogans (redneck equivalents)[1]. I can't say I've heard of anyone doing it.

    Plus I'm not sure if that structure actually qualifies as a sukkah since it has a corrugated iron roof and Wikipedia tells me that sukkahs[2] are topped with branches.

    [1] This is not a serious statement [2] Not sure if that's the correct plural

  • (disco) in reply to Choonster

    No doubt they have to wear proper clothing.

    http://static.tvtropes.org/pmwiki/pub/images/sucka-back-2.jpg

  • (disco) in reply to boomzilla

    I'm not sure I see the connection between sukkahs, bogans and pimps.

  • (disco) in reply to Choonster
    Choonster:
    I'm not sure I see the connection between sukkahs, bogans and pimps.

    Sukkah kind of sounds like sucker, and pimps stereotypically call people the latter.

  • (disco) in reply to FrostCat

    Ah. That makes sense.

    The movie that the picture is taken from is even called "I'm Gonna Git You Sucka".

  • (disco) in reply to renaissance_design
    renaissance_design:
    "Nononono. We have stalls so one person isn't blocking the whole bathroom with his exclusive access."

    I see you've done this answering-stupid-questions thing before.

  • (disco) in reply to TheCPUWizard
    TheCPUWizard:
    If you look at 100% then I will agree. But I remain confident that the code could be structured so that 95%++ of the code could be tested at minimal cost - which is radically different than "this is a device driver I can't unit test it"
    Yes, that's basically it. My original assertion was that the percentage of code that can be tested by AUT is not 100%. It can be close to 100% (I'd also go for more than 95%), but not all the way there.
  • (disco)

    True story: in a meeting the other day about how version control could help our BI team, someone asked, "Is there a way to prevent people from checking out the object while I'm working on it? We're doing that informally at the moment."

  • (disco) in reply to Yamikuronue

    :facepalm:

    That's why an SCM is not just a shared drive. There's a separate step of saying “this is a version that's good enough to show to others”.

  • (disco) in reply to urkerab
    urkerab:
    I don't either... my understanding was that it replaces* your commit with a commit of what it thinks the merge result should be, but has no particular reason to get the merge correct.

    *Ways and means exist to extract the original commit.

    Correct, to a point. It uses the same underlying (very nice) git merge structure and is very good at detecting when you'll have a conflict. When it detects this, it'll hold up the rebase and let you fix the conflict manually, then you just git rebase --continue to finish the rebase.

    Maybe :hanzo: Meh

  • (disco) in reply to Yamikuronue

    Did you BITCHCOMPLAIN at him and say "NAUGHTY DEVELOPER, SPANK SPANK SPANK"?

Leave a comment on “Source History Information Tool”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article