| jmacs | Could be worth us making a catalogue of engineering mistakes and the methods we could use to prevent them. | 00:30 |
|---|---|---|
| persia | jmacs: I've not yet found the article I remember reading before, but http://marc.info/?l=linux-kernel&m=111314792424707 includes some discussion of git as a content-addressible filesystem vs. a traditional SCM (never mind a VCS). | 00:59 |
| persia | Oh, and I thought of a simple thought experiment to demonstrate the lack of real history. Consider two developers, each working on multiple branches, and each regularly rebasing their branches against both their own master and each other's master, with all changes landed as fast-forwards. Over the course of the development, as each developer has no control over when their counterparty chooses to rebase, the two histories may not match, especially | 01:06 |
| persia | if both land changes on their master immediately after rebasing to each other. | 01:06 |
| persia | Or, hrm, maybe it works better with three developers. | 01:07 |
| persia | So, yeah, developer A makes a tree available with patch Z. | 01:07 |
| persia | Developer B rebases patch Y above patch Z, and makes that tree available. | 01:08 |
| persia | Developer C rebases patch X above patch Z, and makes that tree available. | 01:08 |
| persia | Developer A pulls developer B's tree, and then adds patch W. | 01:09 |
| persia | Developer B pulls developer C's tree, and applies patch X. | 01:10 |
| persia | Developer A pulls developer B's tree, and applies patch X. | 01:11 |
| persia | Developer B pulls developer A's tree, with one of two results: either A) patch W is inserted between Y and X or B) patch W is applied over patch X. | 01:12 |
| persia | In the first case, Developer B's local history has changed, and the prior history is not trivially accessible. In the second case, Developer A and Developer B have different histories in their trees. | 01:12 |
| persia | Although the code is precisely the same in both cases (remember, we're assuming no conflicts), the difference in history makes it hard to assert that a given SHA1-marked commit occupies a given position in a version ordering. | 01:13 |
| persia | Of course, one can work around this by having a central git repo and discouraging developers from pulling from each other directly, especially if one prevents any pushes to the central repository that would break history. | 01:16 |
| * persia still thinks it is possible to create this problem with two developers, but hasn't thought it through properly. Something about using different branches in the local repos instead of more developers. | 01:16 | |
| *** AlisonChaiken has joined #trustable | 05:22 | |
| *** ctbruce has joined #trustable | 08:25 | |
| *** LaurenceUrhegyi has joined #trustable | 08:47 | |
| *** toscalix has joined #trustable | 09:03 | |
| *** LaurenceUrhegyi has quit IRC | 10:06 | |
| *** LaurenceUrhegyi has joined #trustable | 10:25 | |
| paulsherwood | rjek: omg | 10:37 |
| rjek | paulsherwood: oyg? | 10:38 |
| paulsherwood | that aes article | 10:39 |
| rjek | Oh the ruby one | 10:39 |
| rjek | yes, terrifying isn't it? | 10:39 |
| persia | jmacs: My apologies, but I think I will never find the interview where Linus explains git as a content-addressible-filesystem, rather than a VCS. The search space for pages on the internet containing "git" and keywords that might help is too large. | 12:48 |
| persia | The mail linked above is about as close as I can reach. | 12:48 |
| persia | The git book, and some other explanations of git plumbing help underscore some of the key issues, like that a git repository can have an arbitrary number of parentless commits, each with a separate history (and no intertwining of histories). That the nature of gc means that it is trivial to lose commits if they are not saved in some way, etc. | 12:49 |
| jmacs | Yes | 14:08 |
| jmacs | I'm learning a lot about git this week; unfortunately I don't think I'll have time to become a master of it | 14:08 |
| persia | For the purpose of asserting criteria to determine whether sufficient metadata is present (and uncorrupted) in a given workflow, I don't think git mastery is required. | 14:21 |
| *** mdunford has quit IRC | 14:25 | |
| *** mdunford has joined #trustable | 14:40 | |
| *** LaurenceUrhegyi has quit IRC | 15:09 | |
| *** mdunford has quit IRC | 15:14 | |
| jmacs | btw, I've started a glossary at https://gitlab.com/trustable/overview/wikis/pages/glossary for people to disagree with | 15:18 |
| *** LaurenceUrhegyi has joined #trustable | 15:22 | |
| persia | jmacs: How does version control imply branching and merging? Most CVS users did without those features for years. | 15:31 |
| jmacs | I used CVS for years and used features analogous to branching and merging. They may not have been called that. | 15:32 |
| * persia is hoping to discover something about the specific semantic mapping implied by the definition, rather than claim the entry is incorrect. | 15:32 | |
| jmacs | I did say "usually implies" | 15:33 |
| persia | Ah, fair. And if I pick another odd-VCS (the debian package archive), there are analogous constructs there as well. | 15:33 |
| persia | So, for the purposes of these discussions, we aren't making an explicit differentiation between Version Control and Source Code Management. | 15:34 |
| jmacs | I think I might, if I can pin down the difference. | 15:34 |
| persia | To me, the difference is entirely about version ordering. | 15:35 |
| persia | Or, well, also an assertion that in a VCS, one is dealing with some particular thing, whereas in an SCM, one might be dealing with a variety of things (e.g. multirooted git repo with different branches corresponding to different projects with no shared history) | 15:36 |
| jmacs | Something like Android's "repo" tool? | 15:36 |
| * persia pauses to learn a bit | 15:37 | |
| persia | At first glance, repo seems to provide management for multiple git reposiitories as a logical unit, which is the inverse of the example I gave above, but broadly, yes, I consider repo to be SCM, but not VCS (except that because it presumes upload to gerrit, centralised gerrit provides VCS-like guarantees for anything merged to managed branches) | 15:39 |
| persia | Conversely, ftp.gnu.org is a VCS (it provides versioned source and authenticity guarantees for specific versions), but it doesn't have any of the features we expect from SCM. | 15:46 |
| jmacs | I can see how ftp.gnu.org functions as a VCS, but I don't think anyone would call it one | 15:50 |
| * paulsherwood thinks persia is being persia again | 15:55 | |
| persia | Not a lot of people call the Debian archive a VCS either :) That said, there is tooling (mostly by GNU) that allows one to show changes between versions, upload new versions, verify that a given codebase is a specific version, etc. | 15:55 |
| rjek | I don't think persia can do much about being persia | 15:56 |
| persia | paulsherwood: Well, yes, but that's why I specifically asked if it was interesting to differentiate VCS from SCM. If it is, then I'm going to pick corner cases that demonstrate things that are one, but not the other. | 15:56 |
| persia | Most tooling in the VCS/SCM area does a bit of both. For all that I argue git isn't a VCS, most git hosting solutions do provide VCS (although some git folk argue against centralised git as "doing it wrong"). | 15:57 |
| persia | (or stronger words, ad hominem attacks, etc.) | 15:57 |
| persia | But if evaluating tools for trust, the data model becomes important. For example, in the case of git, cloning a git repo isn't enough to be confident in history: one also needs metadata from a centralised git hosting solution to audit that the history wasn't changed over time. WIth something like Visual Source Safe, a copy of the repository is enough to be confident of history (at least until the last file rename of any given file). | 16:03 |
| persia | Tools like gitano and gerrit are more interesting than some of the alternatives, because they (do, may) store some of that crtiical metadata in git, so that one doesn't need to use alternate tooling to verify whether the git history is accurate. | 16:08 |
| jmacs | I feel like at some point on this project, someone is going to write a new version control system | 16:24 |
| paulsherwood | oh please no | 16:25 |
| persia | I hope not. There are enough good VCS solutions that live atop git. | 16:27 |
| persia | It might be nice to have one formally part of git "porcelain", or at least agreement on metadata formats to allow transfer between systems, but that's as much as ought be done. | 16:28 |
| *** toscalix has quit IRC | 16:58 | |
| *** LaurenceUrhegyi has quit IRC | 17:04 | |
| *** ctbruce has quit IRC | 17:12 | |
| *** sambishop has quit IRC | 17:40 | |
| *** AlisonChaiken has quit IRC | 17:58 | |
| *** tiagogomes has quit IRC | 18:37 | |
| *** AlisonChaiken has joined #trustable | 21:19 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!