Not in the mood for jokes
-
This week our TeamCity builder[^] came to a grinding halt with a PostgreSQL error: "
ERROR: out of shared memory". I reported the issue on the JetBrains website here: https://youtrack.jetbrains.com/issue/TW-70415[^] And although the folks at JetBrains responded quickly, solving the problem will probably take a long time and we will have to wait for the next update. We have been using TeamCity for years and this is the first time we had a "showstopper" like this. The trouble started after a large commit of the Boost library with more than 14000 files. The repo we use is quite large and dates back to 15 years ago, it was converted to Git from a SVN repo some years ago, and is probably full of garbage. A short term solution is to copy the Git repo and do a file-based checkin to a new repo, we will lose the history but it allows us to keep building. -
This week our TeamCity builder[^] came to a grinding halt with a PostgreSQL error: "
ERROR: out of shared memory". I reported the issue on the JetBrains website here: https://youtrack.jetbrains.com/issue/TW-70415[^] And although the folks at JetBrains responded quickly, solving the problem will probably take a long time and we will have to wait for the next update. We have been using TeamCity for years and this is the first time we had a "showstopper" like this. The trouble started after a large commit of the Boost library with more than 14000 files. The repo we use is quite large and dates back to 15 years ago, it was converted to Git from a SVN repo some years ago, and is probably full of garbage. A short term solution is to copy the Git repo and do a file-based checkin to a new repo, we will lose the history but it allows us to keep building.I know your pain :sigh: . We have used Visual SourceSafe for 20 years now. Yes, I know that SourceSafe is as good a source control joke as Access is a data base joke. What we've found however is that given proper maintenance (which we learned with only a modicum of pain), SourceSafe is eminently reliable. Microsoft abandoned SourceSafe after the update for Visual Studio 2005. Interestingly, there have been Visual Studio extensions written to provide SourceSafe integration for all of the versions since then that didn't include it out-of-the-box. Part of our practice has been judicious management of third-party code. Boost is a good example, which we use with an internal diagnostic tool. None of our copies of Boost are "checked in" to source control. Instead, they are installed directly on our build servers. The tool project is set to look in the proper folders depending on whether it's building locally or on a server. Boost is big enough that I don't think we even could check it into a SourceSafe data base, given the guidance we've followed on data base size. I think part of what makes this a reasonable approach is that we don't alter Boost in any way when a new version is released. We also don't update to every new version. I think that obviates the usual need for source control.
Software Zen:
delete this; -
I know your pain :sigh: . We have used Visual SourceSafe for 20 years now. Yes, I know that SourceSafe is as good a source control joke as Access is a data base joke. What we've found however is that given proper maintenance (which we learned with only a modicum of pain), SourceSafe is eminently reliable. Microsoft abandoned SourceSafe after the update for Visual Studio 2005. Interestingly, there have been Visual Studio extensions written to provide SourceSafe integration for all of the versions since then that didn't include it out-of-the-box. Part of our practice has been judicious management of third-party code. Boost is a good example, which we use with an internal diagnostic tool. None of our copies of Boost are "checked in" to source control. Instead, they are installed directly on our build servers. The tool project is set to look in the proper folders depending on whether it's building locally or on a server. Boost is big enough that I don't think we even could check it into a SourceSafe data base, given the guidance we've followed on data base size. I think part of what makes this a reasonable approach is that we don't alter Boost in any way when a new version is released. We also don't update to every new version. I think that obviates the usual need for source control.
Software Zen:
delete this;We have a lot of binaries, mostly 3rd party libraries, which are not ideal for storage in Git. That's why I tried to use Git LFS (Large File Storage), but it was a total failure. The git lfs migrate command did not work, and when trying to add only one subdirectory to a new repo it doubled in size. I wonder if anyone got this working on Git for Windows, not talking about the whole repo but a subdirectory like this:
git lfs migrate import --include="common/**"
-
We have a lot of binaries, mostly 3rd party libraries, which are not ideal for storage in Git. That's why I tried to use Git LFS (Large File Storage), but it was a total failure. The git lfs migrate command did not work, and when trying to add only one subdirectory to a new repo it doubled in size. I wonder if anyone got this working on Git for Windows, not talking about the whole repo but a subdirectory like this:
git lfs migrate import --include="common/**"
RickZeeland wrote:
The git lfs migrate command did not work
"Did not work" is hardly specific enough. :laugh:
The difficult we do right away... ...the impossible takes slightly longer.
-
This week our TeamCity builder[^] came to a grinding halt with a PostgreSQL error: "
ERROR: out of shared memory". I reported the issue on the JetBrains website here: https://youtrack.jetbrains.com/issue/TW-70415[^] And although the folks at JetBrains responded quickly, solving the problem will probably take a long time and we will have to wait for the next update. We have been using TeamCity for years and this is the first time we had a "showstopper" like this. The trouble started after a large commit of the Boost library with more than 14000 files. The repo we use is quite large and dates back to 15 years ago, it was converted to Git from a SVN repo some years ago, and is probably full of garbage. A short term solution is to copy the Git repo and do a file-based checkin to a new repo, we will lose the history but it allows us to keep building.Welcome to development, many more unexpected "challenges" will come your way :-\ And I could not not. There's always something.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
Welcome to development, many more unexpected "challenges" will come your way :-\ And I could not not. There's always something.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
Quote:
And I could not not
Does that mean that you got Git LFS working on a subdirectory?
-
Welcome to development, many more unexpected "challenges" will come your way :-\ And I could not not. There's always something.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
Absolutely must-see[^] :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Absolutely must-see[^] :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
