• (nodebb)

    I've worked at a place which, even though they used source control for the database, demanded that we include a "change log" at the top of the stored proc because it was "easier to see when working on it". The same place also forbade formatting the document because it messed up the Diff.

  • Angela (unregistered)

    I have to deliver source to a customer that has no access to our source control. So this is a requirement. I have to nag people to do it, it's a pain.

  • (author) in reply to Angela

    I'm sure there are constraints around why you can't use it, but this is 100% what Git is good at. Internal remote for development, external facing remote for your customers.

  • (nodebb) in reply to Angela

    If the customer needs source history, they should get source history. There's no guarantee that the comments accurately reflect the source history.

    As Remy said, Git is really good for this. But you don't necessarily need an externally-accessible repository. If you have to deliver history along with the source code, just deliver a Git bundle file.

  • (nodebb)

    Is no one going to mention Remy's typo in the title? Or am I TRWTF because it was intended irony?

  • Angela (unregistered) in reply to Dragnslcr

    Git didn't exist when the project started and I'm not sure anyone wants to make the transition from Clearcase exactly for fear of losing that history.

  • PotatoEngineer (unregistered) in reply to Remy Porter

    Okay, so swearing goes in the Git commit message, not in the source code comments. Got it.

  • (nodebb) in reply to ObiWayneKenobi

    Look, the change log had a lot to do with not everyone who worked on the procedures being included in the licensing when we finally got tooling set up to source-control the database, and the original idea was supposed to be that formatting should always be its own commit, but then we couldn't get the senior dev to fix his line ending settings or everyone to standardize on tabs or spaces plus we had to keep dealing with formatting changes from the folks who didn't have the source control tooling and...

    uh...

    ok you probably didn't really work with me before, but yeah, definitely hits close to home.

  • Registered (unregistered)

    Sooner or later someone will use calculateMassGrossPay() to write the checks and everyone will have to track down the reason no one was paid.

  • asdf (unregistered)

    A nice thing about compiled languages is that the compiler will tell you in no uncertain terms if you try calling a non-existent function.

  • COBOL Dilettante (unregistered)

    I was on a call recently where our internal auditors wanted to know why the control developers hadn't removed the line of code from their script that they'd been told to remove a few years ago.

    Turns out they had "removed" it, it's just the auditors didn't know what "--" means in SQL ... which has taught me a new reason why you should actually delete code instead of commenting it out

  • DrPepper (unregistered) in reply to Angela

    This is something that AI is really good at. Have the AI generate the comment from the diff, and include it as a comment at the top of the source file as it is bundled up to deliver to the customer. And if the comment REALLY needs to be in the source file permanently, have AI generate that comment and insert it before committing the code to the repo. And, you might as well have the AI write the commit message too, while you're at it.

  • Angela (unregistered) in reply to DrPepper

    Maybe we'll have AI tools in a couple decades, and I am not exaggerating. We don't even have widely available tools like Jira, etc.

  • (nodebb)

    "VSS was terrible" is wrong. It's "VSS is terrible". Everyone moves off VSS as soon as they learn of better systems. There are way too many problems with VSS including the inability to make change sets so if you modify multiple files someone else can get a copy of the code that doesn't build because someone was halfway through checking in code.

    As for change logs in file headers, most source control systems support adding it automatically - just read how you can put a tag and the source control system will automatically add the commit header to your file. And ones that don't I'm sure there's extensions/hooks/etc that can add them automatically.

  • enkorvaks (unregistered) in reply to Angela

    ClearCase can do exports, which can then be imported. But I understand no-one wanting to do that. There's also the option of "move the current release to git, reduce the ClearCase licence count to 3, keeping it only for history reasons". I suspect no one wants to foot the bill for the change, though, even if there is a reasonable saving on licence costs...

    I will say that ClearCase is good for Configuration Management (assuming it has been set up and run competently), which no other version control tools do (they do Version Control, not Configuration Management - there's a distinct difference). As a result, changing to git will incur a cost as your organisation works out how to add Configuration Management to the git workflow. (And, presumably, no one wants to foot the bill for that, either)

  • Westy (unregistered)

    Is the misspelling "safegaurd" intentional and I've missed something subtle?

  • (nodebb) in reply to Worf

    I used VSS for Far Too Long because I didn't want to lose the change history.

    I finally bit the bullet and wrote something that would migrate the VSS repo to git via checking out each VSS change then checking it in to the new git repo, thus preserving the history.

  • Drak (unregistered) in reply to asdf

    True, but imagine the surprise 3 years later when some piece of bespoke code has to be updated for a customer (because maybe some API somewhere changed a route) and it turns out that instead of a quick 15 minute fix you need to go figure out what a function which was deleted 3 years ago did, and what to call now, and whether the new function really still does what this code needs it to do.

  • 516052 (unregistered) in reply to Drak

    To answer in order of your questions:
    It does everything for everyone and yet nothing for no one. Realistically you need to write new code but you don't have the time or budget for that so you need to reuse stuff even when it does not fit and hack at the result. And the function maybe, possibly once did what you need it to. But it's not likely. However everyone but you including your boss who is just proficient enough to look at the code but not enough to understand it (as in, just enough to be dangerous) is convinced that it does.

    Welcome to software development.

  • (nodebb) in reply to Worf

    There are way too many problems with VSS including the inability to make change sets

    I see that there is no mention of:

    % "timestamps inside metadata are generated by the client using its view of the time", combined with "the placement of labels is based on timestamps", which means that machine 2 can, without meaning to, place a label earlier in sequence than a checkin that has already been made by machine 1. This tends to come as a surprise when you discover that (as it was at the time we found this) Windows 2000 doesn't by default automatically sync time.

    % VSS's own diagnostic tools report three errors with a brand new depot that has just this moment been created.

    % VSS almost inevitably starts corrupting the depot as soon as it goes over 2 GB of file data and metadata (commit comments, labels, branch info, etc.)

    % File type information and file name information are not versioned. If you rename a file, or switch it between binary and text, it changes for all of the file's history, meaning that you can no longer build 1.1 because when you fetch it for an emergency patch after the release of 2.0 (that renamed three important files), you get the new names, not the old names, and all the #include directives (in 1.1) that referenced those files fail.

    All that is why my own preferred name for it is VSH - Visual Source Hazard.

  • (nodebb)

    I don't think I ever lost history with VSS... However, migrating Source Control is the history killer. We migrated three times, with one iteration involving a tool to reproduce the old repository's history into the new one, and even that didn't work perfectly. Our latest migration, from an Azure DevOps TFS repository to an Azure DevOps Git repository, had Microsoft's own documentation outright stating "You can migrate up to the last six months of history if you're into that, but you shouldn't even bother to try".

    Addendum 2026-02-26 04:20: Our history went back over a decade, so this "up to six months" comment felt like a 1¢ coin thrown at my face.

  • (nodebb)

    This is how i remember my father used to document changes in his FORTRAN code back in the day (talking about 1980s/1990s), because source control systems weren't used that much back then, especially in his field of work (chemical/physics research)

  • Frank Wilhoit (unregistered)

    SourceSafe was originally a product of One Tree Software -- a very popular product, as, say what you might of it, it was better and cheaper than anything else then (1994ish) in the market.
    Microsoft offered to buy them out, for, let us say, fifty moneys. They refused indignantly. Microsoft then sent out a blast fax announcing the imminent release of Microsoft Delta, the ultimate dream source-control system. One Tree's sales dropped to zero. Microsoft then went back to them and said, how about twenty moneys? And they sold. Microsoft Delta of course never existed apart from that blast fax.

  • erffrfez (unregistered)

    I think this would be improved if instead of doing nth, it did (n+1)th

  • erffrfez (unregistered) in reply to erffrfez

    and I'm glad to see that this will only be affected by any change, not chance. That should safegaurd things enough for me

  • TechHound (unregistered) in reply to asdf

    asdf:

    A nice thing about compiled languages is that the compiler will tell you in no uncertain terms if you try calling a non-existent function.

    This also true of many interpreted language as well.

  • (nodebb) in reply to DrPepper

    Why does everybody suddenly think AI is the answer to everything?

    Including the change log in a piece of source code that is to be distributed to a customer is trivially easy to anybody with basic scripting skills. Some older source control systems could do it automatically with keyword substitution. In fact, maybe ClearCase is one of them.

  • enkorvaks (unregistered) in reply to jeremypnet

    "Some older source control systems could do it automatically with keyword substitution. In fact, maybe ClearCase is one of them."

    Yes, ClearCase could. Some of it was essentially automatic (very similar to RCS/CVS substitution, where things like $Id$ are replaced), but almost anything could be done by writing a Perl script, and installing it as a 'pre-checkin trigger'. (Yes, Perl was the language of choice at the time I was using ClearCase, because Python 1.2 was a joke, not a programming language. I'm not being disparaging, it was considered a joke, even in the documents describing how to use the language.)

  • Craig (unregistered) in reply to Medinoc

    We've migrated ~10+ years of history from local TFS to GitHub and ~20+ years of history from P4 to GitHub. It's weird that Microsoft would have a 6 month limitation on migration to Azure DevOps Git.

  • (nodebb)

    Since it's impossible to enter there, no need to tell them to abandon all hope.

Leave a comment on “Safegaurd Your Comments”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article