Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>Yes, I know, Linus never intended it for that.</p> </blockquote> <p>Actually, Linus argues that centralized systems just can't work. </p> <p>And, what's wrong with the <a href="http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows#Dictator-and-Lieutenants-Workflow" rel="nofollow noreferrer">dictator-and-lieutenants workflow?</a></p> <p><img src="https://git-scm.com/figures/18333fig0503-tn.png" alt="diagram"></p> <p>Remember, git is a <em>distributed</em> system; don't try to use it like a central one.</p> <h3>(updated)</h3> <p>Most of your problems will go away if you don't try to use git as if it was "svn on steroids" (because it's not).</p> <p>Instead of using a bare repository as a central server where everyone can push to (and potentially screw up), setup a few integration managers that handle merges, so that only they can push to the bare repository. </p> <p>Usually these people should be the team leads: each leader integrates his own team's work and pushes it to the blessed repository.</p> <p>Even better, someone else (i.e. dictator) pulls from the team leaders and integrates their changes into the blessed repository.</p> <blockquote> <p>There's nothing wrong with that workflow, but we're an overworked startup and need our tools to substitute for human time and attention; nobody has bandwidth to even do code reviews, let alone be benevolent dictator. </p> </blockquote> <p>If the integrators don't have time to review code, that's fine, but you still need to have people that integrate the merges from everybody.</p> <p>Doing git pulls doesn't take all that much time. </p> <pre><code>git pull A git pull B git pull C </code></pre> <p>git <em>does</em> substitute for human time and attention; that's why it was written in the first place.</p> <blockquote> <ul> <li>The GUI tools aren't mature</li> </ul> </blockquote> <p>The gui tools can handle the basic stuff pretty well. </p> <p>Advanced operations require a coder/nerdy mindset (e.g. I'm comfortable working from the command line). It takes a bit of time to grasp the concepts, but it's not that hard.</p> <blockquote> <ul> <li>Using the command line tools, it's far to easy to screw up a merge and obliterate someone else's changes</li> </ul> </blockquote> <p>This won't be a problem unless you have many incompetent developers with full write access to the "central repository". </p> <p>But, if you set up your workflow so that only a few people (integrators) write to the "blessed" repository, that won't be a problem.</p> <p>Git doesn't make it easy to screw up merges.</p> <p>When there are merge conflicts, git will clearly mark the conflicting lines so you know which changes are yours and which are not.</p> <p>It's also easy to obliterate other people's code with svn or any other (non-dsitributed) tool. In fact, it's way easier with these other tools because you tend to "sit on changes" for a long time and at some point the merges can get horribly difficult.</p> <p>And because these tools don't know how to merge, you end up always having to merge things manually. For example, as soon as someone makes a commit to a file you're editing locally, it will be marked as a conflict that needs to be manually resolved; now <em>that</em> is a maintenance nightmare.</p> <p>With git, most of the time there won't be any merge conflicts because git can actually merge. In the case where a conflict does occur, git will clearly mark the lines for you so you know <em>exactly</em> which changes are yours and which changes are from other people.</p> <p>If someone obliterates other people's changes while resolving a merge conflict, it won't be by mistake: it will either be because it was necessary for the conflict resolution, or because they don't know what they're doing.</p> <blockquote> <ul> <li><p>It doesn't offer per-user repository permissions beyond global read-only or read-write privileges</p></li> <li><p>If you have a permission to ANY part of a repository, you can do that same thing to EVERY part of the repository, so you can't do something like make a small-group tracking branch on the central server that other people can't mess with.</p></li> <li>Workflows other than "anything goes" or "benevolent dictator" are hard to encourage, let alone enforce</li> </ul> </blockquote> <p>These problems will go away when you stop trying to use git as if it was a centralized system.</p> <blockquote> <ul> <li>It's not clear whether it's better to use a single big repository (which lets everybody mess with everything) or lots of per-component repositories (which make for headaches trying to synchronize versions).</li> </ul> </blockquote> <p>Judgment call.</p> <p>What kind of projects do you have? </p> <p>For example: does version x.y of project A depend on exactly version w.z of project B such that <em>every time</em> you check x.y of project A you also have to checkout w.z of project B, otherwise it won't build? If so I'd put both project A and project B in the same repository, since they're obviously two parts of a single project.</p> <p>The best practice here is to <a href="https://stackoverflow.com/questions/406760/whats-your-most-controversial-programming-opinion/406775#406775">use your brain</a></p> <blockquote> <ul> <li>With multiple repositories, it's also not clear how to replicate all the sources someone else has by pulling from the central repository, or to do something like get everything as of 4:30 yesterday afternoon.</li> </ul> </blockquote> <p>I'm not sure what you mean.</p>
    singulars
    1. This table or related slice is empty.
    1. POGit-Based Source Control in the Enterprise: Suggested Tools and Practices?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USCommunity
    1. UShasen
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThere's nothing wrong with that workflow, but we're an overworked startup and need our tools to substitute for human time and attention; nobody has bandwidth to even do code reviews, let alone be benevolent dictator. Anybody who has write permissions can - and does - accidentally push crap into the central repository. You can certainly push crap with other source control systems, but I find that, compared with git, other systems I've used make it easier to do merges and avoid the crap, and to back up to before crap someone else has pushed.
      singulars
      1. PO
      1. USBob Murphy
    2. COAnd as far as the politics, if you're a peaceable person, I doubt you'd like it. As I said, we're an overworked startup with a lot of very smart, opinionated, young, energetic, inexperienced, immature developers. We surf a giant wave of barely controlled chaos, and among the things that are flying under management's radar is the CM system. As a 51-year-old, I survive by being a badass who can out-fight (martial arts), out-drink (single malt Scotch) and out-code any of the twenty-somethings. And I feel a responsibility to protect those among my colleagues who are suffering but not aggressive...
      singulars
      1. PO
      1. USBob Murphy
    3. CO... Anyway, we've got git because some of the early hires put it in place. Their attitude is, "I love git, and if it doesn't work for you, too bad, suck it up." And they're aggressive enough about it, other people have given up. So I'm trying to figure out if we can make it work for the people who are having problems, or if I'm going to make an issue of it. But I hate having to do this sort of "who's willing to go to the mat hardest" nonsense, and would rather just make rational decisions based on organizational needs, then go home, put on my slippers, and hang with my wife.
      singulars
      1. PO
      1. USBob Murphy
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload