4 ms·

Single repo is one design that coherently addresses source control management and dependency management. The key is to let the repo be a single comprehensive s

Single repo is one design that coherently addresses source control management and dependency management. The key is to let the repo be a single comprehensive source of data for building arbitrary artifacts.

evfanknitram 8y ago
I don't know what this means. How is "single repo" a "design" and how does this design dictate dependency management? Yes, if you have a single repo then that would be a single source of data for building your stuff. That seems redundant.
- justicezyx 8y ago
  See Bazel, you have the depes manifested as source controlled the data, then you can build everything as deterministically as possible. Then you can manage dependency as part of the normal source control process.
MaxBarraclough 8y ago
> The key is to let the repo be a single comprehensive source of data for building arbitrary artifacts. By that do you mean it's one way of doing it, or that it's the only way? Seems clear to me that it's not the only way. For instance .Net code tends to be Git for the project source + NuGet for external dependencies. It works pretty well.
- justicezyx 8y ago
  It's one way. There isnt any problem that can only be solved in one way.
adrianN 8y ago
A single repo makes it a bit tricky to use some library in version A for project X and version B for project Y.
- paulddraper 8y ago
  Correct. You can consider that a bad thing or a good thing. Most language's package composition (C/C++, Java, Python, Ruby) don't permit running multiple versions at runtime. The single-version policy is one way of addressing dependency hell.
- bunderbunder 8y ago
  I think that's actually a good thing. Allowing different projects to use different versions of a 3rd-party package may be convenient for developers in the short term, but it creates bigger problems in the long term.
  - adrianN 8y ago
    It depends on the industry. In some places changing a dependency, no matter how trivial the change, entails a lot of work. Think for example about embedded systems where deploying is a lot harder than pushing a Docker image somewhere. It is often far cheaper to analyze whether the fixed bug can be triggered to avoid upgrading unless necessary.
    - bunderbunder 8y ago
      In those situations, why not go ahead and keep the code up-to-date and consistent, and simply not deploy when you don't need to?
      - adrianN 8y ago
        Because that costs money now that could be spent on something that actually produces a profit.
- Nihilartikel 8y ago
  If I recall, in Google's build system, a dependency in the source tree can be referenced at a commit ID, so you can actually have a dependency on an earlier version of artifacts in source control.

evfanknitram 8y ago

I don't know what this means. How is "single repo" a "design" and how does this design dictate dependency management? Yes, if you have a single repo then that would be a single source of data for building your stuff. That seems redundant.

justicezyx 8y ago
See Bazel, you have the depes manifested as source controlled the data, then you can build everything as deterministically as possible. Then you can manage dependency as part of the normal source control process.

MaxBarraclough 8y ago

> The key is to let the repo be a single comprehensive source of data for building arbitrary artifacts. By that do you mean it's one way of doing it, or that it's the only way? Seems clear to me that it's not the only way. For instance .Net code tends to be Git for the project source + NuGet for external dependencies. It works pretty well.

justicezyx 8y ago
It's one way. There isnt any problem that can only be solved in one way.

adrianN 8y ago

A single repo makes it a bit tricky to use some library in version A for project X and version B for project Y.

paulddraper 8y ago
Correct. You can consider that a bad thing or a good thing. Most language's package composition (C/C++, Java, Python, Ruby) don't permit running multiple versions at runtime. The single-version policy is one way of addressing dependency hell.
bunderbunder 8y ago
I think that's actually a good thing. Allowing different projects to use different versions of a 3rd-party package may be convenient for developers in the short term, but it creates bigger problems in the long term.
- adrianN 8y ago
  It depends on the industry. In some places changing a dependency, no matter how trivial the change, entails a lot of work. Think for example about embedded systems where deploying is a lot harder than pushing a Docker image somewhere. It is often far cheaper to analyze whether the fixed bug can be triggered to avoid upgrading unless necessary.
  - bunderbunder 8y ago
    In those situations, why not go ahead and keep the code up-to-date and consistent, and simply not deploy when you don't need to?
    - adrianN 8y ago
      Because that costs money now that could be spent on something that actually produces a profit.
Nihilartikel 8y ago
If I recall, in Google's build system, a dependency in the source tree can be referenced at a commit ID, so you can actually have a dependency on an earlier version of artifacts in source control.