3 ms·

Yes, your advice is sound for the general case but inapplicable in this specific incarnation of the problem.

by Xylakant 12y ago

angersock 12y ago
Out of curiosity, what is the gist of your setup? Why is this incarnation such a departure from the general case?
- Xylakant 12y ago
  The output of the build is basically a tool in itself. So most people don't need the build process, just the resulting tool. The input changes on pretty much a monthly basis and is not easily versioned. I could set up all dev machines to support the build and everybody could build it themselves from sources, but that would require me to * install all the required instruments for the ritual rain dance * teach the whole team how to do the ritual rain dance * support the people that break an arm or a leg doing the ritual rain dance So I prefer perform the dance on my machine, collect the tool and point the main dev environment to the right location. It's all scripted, so I kick off the job and grab a coffee. However, I want to keep old instances around so I can track when bugs crept in, so I can't just go overwrite the result, so I need to adjust the pointer every time. If I could just check the tool in with the regular dev setup that would be much easier, but - since we're using git - that would blow up quite quickly and overwhelm my disk space. (And folks would kill me for filling up their disks as well - rightfully so). That's something SVN or another centralized VCS would handle much more gracefully. In a gist, I have a use-case for fairly stupid versioned file storage with a push/pull api. No complicated merging, no branching, nothing. git-annex could do, but is overkill. There are some better solutions to what we're currently doing, but there's so many yaks to shave and so few razors.
  - pyre 12y ago
    > That's something SVN or another centralized VCS would handle much more gracefully. Subversion handles this gracefully because you don't download all of the repository's history to your machine. It's a trade-off that you're talking about here. Most people are ok with losing the ability to check in 500MB files in order to gain the decentralization of having a full copy of the repo (and not needing to query the server just to view history).
  - gknoy 12y ago
    Thanks for such a good explanation. When I first saw artifacts of things generated by code in our repo, I had a big WTF moment, but it made a lot of sense once someone pointed out that it was Rather Handy for catching bugs in the code that does the generation.

Yes, your advice is sound for the general case but inapplicable in this specific incarnation of the problem.

angersock 12y ago

Out of curiosity, what is the gist of your setup? Why is this incarnation such a departure from the general case?

Xylakant 12y ago
The output of the build is basically a tool in itself. So most people don't need the build process, just the resulting tool. The input changes on pretty much a monthly basis and is not easily versioned. I could set up all dev machines to support the build and everybody could build it themselves from sources, but that would require me to * install all the required instruments for the ritual rain dance * teach the whole team how to do the ritual rain dance * support the people that break an arm or a leg doing the ritual rain dance So I prefer perform the dance on my machine, collect the tool and point the main dev environment to the right location. It's all scripted, so I kick off the job and grab a coffee. However, I want to keep old instances around so I can track when bugs crept in, so I can't just go overwrite the result, so I need to adjust the pointer every time. If I could just check the tool in with the regular dev setup that would be much easier, but - since we're using git - that would blow up quite quickly and overwhelm my disk space. (And folks would kill me for filling up their disks as well - rightfully so). That's something SVN or another centralized VCS would handle much more gracefully. In a gist, I have a use-case for fairly stupid versioned file storage with a push/pull api. No complicated merging, no branching, nothing. git-annex could do, but is overkill. There are some better solutions to what we're currently doing, but there's so many yaks to shave and so few razors.
- pyre 12y ago
  > That's something SVN or another centralized VCS would handle much more gracefully. Subversion handles this gracefully because you don't download all of the repository's history to your machine. It's a trade-off that you're talking about here. Most people are ok with losing the ability to check in 500MB files in order to gain the decentralization of having a full copy of the repo (and not needing to query the server just to view history).
- gknoy 12y ago
  Thanks for such a good explanation. When I first saw artifacts of things generated by code in our repo, I had a big WTF moment, but it made a lot of sense once someone pointed out that it was Rather Handy for catching bugs in the code that does the generation.