Version Control Questions Megathread (SVN / git / whatever else)

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Version Control Questions Megathread (SVN / git / whatever else)

«‹›2 »

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

I wanted to post this and see if anyone has any thoughts on how wrong our team is regarding CM. I know we're not right, I just don't know how wrong. (wall of text notice)

---

Some background: our team uses clearcase for version control, dictated by higher management. Not one of us has any real-world experience with it, and getting someone with said isn't in the cards, so me and one other guy have been winging it with the scant training available for this dozen-person team. Not a good start, I know.

What we do right now is this: we reserve /main/ to hold file versions for milestone releases--1.0, 2.0, whatever goes into the wild. We don't support or code for old releases, mind; we're keeping them only because management wants history. Whatever. Anyway, what we settled on was making, off of /main/, one branch per minor release (so /main/bld1.0/, /main/bld1.1/, etc). Branched off THOSE are minor releases, and finally, branched off those are development branches. So one developer might be coding in /main/bld1.0/bld1.0.4/req22/, another might be in /main/bld1.0/bld1.0.3/bug3221/, or something.

A typical development area config spec would look like this, to take the last example:

code:

element * CHECKEDOUT
element * .../bug3221/LATEST
element * BUILD_1.0.3 -mkbranch bug3221

BUILD_1.0.3 is a label me and the other CM guy assign to all versions of all files when a successful build is done, so developer's work areas stay stable. These build labels never change once assigned.

When a developer has something to move into the release being worked on, he first updates his config spec so instead of taking from BUILD_X.X.X, it takes from BUILD_LATEST, which we CM guys keep updated to match the most recent build. Then the developer performs a findmerge from BUILD_LATEST into his work branch, updating it with all the changes that have taken place to files he's touched in his baseline since he started development (files he HASN'T touched are taken care of by the config spec change). He performs the merge in his branch, tests it, and passes notice to CM that it's ready, and we insert that branch into the baseline after our own testing. (We have the developer update his code to match latest instead of doing it ourselves because, frankly, we have our own development to do, and CM would turn into, well, the full-time job it bloody well should be if we had to do the reconciling ourselves.)

---

That got a little long winded, sorry--don't know how much detail is too much detail, like I said I have no idea what the hell I'm doing. But are my partner and I at least on something like the right track? It's worked for the past month or two this way, but without having done this before I have no basis for comparison.

# ¿ Apr 8, 2009 17:06

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 13:10

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

BusError posted:

Oh god, I am so sorry. I work (not for much longer, I hope) in an rear end-backwards systems department that thinks IBM shits gold, and we're required to use like every tool they crank out...so far, no one has been able to figure out how to get ClearCase to do anything besides suck up hundreds of hours of time attempting to configure it properly.

Yeah, we're all quite saddened by it too. But whaddaya gonna do besides spend money we don't have on a new suite? vOv

That said, for a couple guys who have no training in the thing and spend most of their time programming anyway, I think my partner and I have a sufficient handle on it. But oh, man, trying to explain to the other developers what they need to do when they have code ready to migrate... :suicide:

# ¿ Apr 16, 2009 16:21

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Reasons You Don't Make A Zero-Experience-In-CM Software Developer Do Clearcase Stuff, #33

Me: "clearfsimport? You telling me I DIDN'T have to do those 300+ checkins/diffs by hand, one at a time? :suicide:

# ¿ Jun 13, 2009 00:37

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Our house has been using Clearcase up to now (I know :suicide:

). Fortunately, with the Solaris->Linux port/upgrade we're working on we've got a chance to change it up, and SVN seems to be the pending winner right now. There anywhere I can read up on how the two differ and what bad habits I'm gonna have to unlearn if any, or should I just start reading the Red Bean book mentioned in the OP?

(I basically got thrown to the dogs on this source control stuff by making the cardinal mistake of volunteering when a coworker left, not knowing a drat thing about the subject. So I probably learned a LOT of bad habits...)

Ciaphas fucked around with this message at 02:25 on Oct 1, 2013

# ¿ Oct 1, 2013 02:21

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Do any of the various SVN GUI applications for UNIX/Linux stand out above the others or are they all pretty equal?

# ¿ Oct 19, 2013 00:12

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Speaking as a mostly clueless newbie to version control*, how would I want to go about picking a version control system to actually use for our team?

We have a very small team, about 1-3 people ever actually coding, we're mostly in maintenance mode code-wise at this point, and our dev machines will never see the internet. Our only real requirement is that we be able to point at a particular tagged release and say "this is where we finished these features/bugfixes". With those minimal requirements I have no idea what's suitable without being Too Damned Much, having hosed around enough to know the very basics of using svn, hg, and git.

^{_{* I ended up as the Clearcase guy for our team these past five years and I hate it, but I learned by trial rather than teaching so I might be biased. Nice conflict merge tools though, I think}}

(edit) Oh lord, did I just step on a highly over-opinionated land mine? :cry:

Ciaphas fucked around with this message at 04:24 on Nov 7, 2013

# ¿ Nov 7, 2013 04:10

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Jam2 posted:

May I ask how you've made it this far without version control?

By beating a lovely old version of Clearcase into submission, mainly :shobon:

We've been using that for a lot longer than I've been here, never upgrading, and since we're changing dev environments I figured I'd look around. So thanks for the answers!

(edit) vv The place is hilariously resistant to change in a lot of ways, and our dev environment's a casualty of that, I suppose. I still like the job, though :saddowns:

Ciaphas fucked around with this message at 08:29 on Nov 7, 2013

# ¿ Nov 7, 2013 08:16

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Sadly, it's all become a bit moot today--my team lead's boss has stated that we're not dumping Clearcase in the near, or likely far, future. Didn't give a reason why, I can only assume he's not interested in causing conflict with the other two teams besides my own (who aren't changing dev environments and so don't have a handy excuse), despite us not sharing any code at all (just database resources). Knowing him and myself, changing his mind isn't happening.

Oh well, still learned quite a bit in this whole adventure, so thanks again for the suggestions.

# ¿ Nov 7, 2013 23:09

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Just screwing around with Git, trying to learn more about administering a central repository for a small dev team. Got a couple questions-

- I've got an update hook that looks something like this (paraphrasing, wrong computer) to stop pushes to master:

code:

#!/bin/bash

ref=$1

if [ $ref == "refs/heads/master" ] && ([ -z $USER ] || [ $USER != "gitadmin" ]); then
  echo "Don't push to master! Push to develop and let Ciaphas know!" >&2
  exit 1
fi

exit 0

Since it's just a small dev team I don't expect anyone to be a butt and do something like env USER=gitadmin git push origin master, but just for curiosities' sake, is there a better way to do that without using any external packages? (I'm still trying to learn just git, without getting gitosis or gitolite or whatever involved)

- Say someone commits a couple times to master in their repo before realizing they're not supposed to push that. What's the 'right' way to fix this? I was thinking a rebase of some sort to get their commits onto their develop branch, delete their master branch, then push develop, but rebasing is still foreign loving witchcraft to me :saddowns:

- If a series of commits becomes unreachable--say by someone deleting an experimental branch without merging it anywhere--what happens to those commits? Do they just stay there taking up space and being mostly inaccessible forever?

(edit: just a background note, we're all coming off of ClearCase if that gives you any indication of how lost in the woods we collectively are :v:

)

(edit) One more, kind of a policy question--is it typical to let finished topic branches sit around forever on the central repo once they're merged in to develop or wherever, or do you delete the branches for cleanliness' sake?

Ciaphas fucked around with this message at 18:34 on Nov 10, 2015

# ¿ Nov 10, 2015 18:27

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

I've got a situation where I'm trying to maintain a repository for two OSes--SunOS and RHEL, in this case. 95%+ of the code and scripts and stuff is the same between the two. I figure I can set up a git repo with linux and sun branches, but that would mean doing two merges for every commit that applies to both branches. Does anyone have any experience with this sort of problem that they can enlighten me with?

# ¿ Feb 25, 2016 21:10

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Ralith posted:

Normally you try to have a single set of code that can be configured at compile time or even run time to support any of the supported target platforms.

Unfortunately there are things like shell scripts using builtins that, no matter how I slice it, just have to be different between the two systems. Process monitoring stuff comes to mind right now. As to the actual C++ code, some of the differences already use directives and such, but most don't, and those aren't gonna be worth the effort to refactor for the timeframe I have to do this for (a couple months at best).

Ithaqua posted:

Assuming Git: Can't you put the common code in a separate repository and have distribution-specific repositories that use submodules to pull in the common code?

Git, yes, sorry. That might work, though I've never used submodules before so there might be some faff.

The other half of that problem is that, as part of moving from Sun to Linux, we're moving off of Clearcase ( :suicide:

) so adapting to things like submodules might be a bit much for the rest of my team. And me for that matter :v:

# ¿ Feb 25, 2016 21:57

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

ExcessBLarg! posted:

Honestly, though, the best option is to have one branch and conditionally-compile platform-specific code. Even with shell scripts, you can usually have a "foo-linux.sh" and "foo-sun.sh" which are called by a master "foo.sh" after determining which OS you're on.

This is probably what we're gonna end up doing really, yeah. Figured I'd explore the alternatives, though, since we're not gonna have to support more than two platforms for more than a year. (I hope. Server hardware purchasing is such a bitch around here like that.)

# ¿ Feb 26, 2016 01:06

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

I want to take a minute to make sure I'm understanding how Git sort of works, especially when rebases get involved. I've got a repo with a master branch (remote tracking a central repo's master branch) and a local-only branch, warnings-fixes, for clearing up a bunch of warnings in our C++ project over time. master is some dozen commits ahead of warnings-fixes at this point, and I'd like to catch warnings-fixes up to see if some warnings got fixed (or new ones got made because apparently people can't be bothered :mad:

)

git rebase master warnings-fixes will replay all of the commits uniquely reachable by warnings-fixes on top of where master currently is, and save them as new commits, correct? Does anything in particular happen to the old commits in that branch? Is this different if there's a remote-tracking or another local branch there before I do the rebase? Will rebasing in this way interfere with anyone?

My guess is "yes, this is what you want; they are brand new commits; the old ones are orphaned unless another branch, remote or otherwise, was at the head before you rebased; it won't interfere with anyone long as you've never pushed warnings-fixes". Is that about right?

Ciaphas fucked around with this message at 01:27 on Mar 12, 2016

# ¿ Mar 12, 2016 01:22

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Cool, thanks, glad I got it right. We're finally freeing ourselves of ClearCase, me and four others, and I'm the designated "train them or figure out what training we need" guy, so I'm busying myself making sure I'm clear on concepts and how things will change (and how things will stay the same) for everyone else.

# ¿ Mar 12, 2016 04:19

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

My coworkers and I are all working in master in a git project, fetching and pushing from a single central bare repo. As a result, when we do git pulls we end up with a lot of merge commits. Not really a problem, but having them sprinkled in the history tree is kind of ugly.

I've taken to doing git fetch; git rebase origin/master master instead which makes things nice and clean; are there any disadvantages to doing things this way instead of using git pull? So far I'm thinking "no--again as long as you haven't pushed anything you rebase" but I want to make sure before I tell the others to start doing this.

(I know we should be working in branches rather than all colliding on master; they're all new to Git after a decade on ClearCase and I'm a rubbish teacher, and there's no money for training for a few months.)

(ed: by the way if anyone can recommend a training company that'd come to Las Vegas and do a course for our team I'd listen :v:

)

Ciaphas fucked around with this message at 00:21 on Mar 23, 2016

# ¿ Mar 23, 2016 00:11

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Well then, that answers that :v:

. I just kind of stumbled into that solution for my own OCD purposes, didn't think it was that common. Thanks!

# ¿ Mar 23, 2016 00:54

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Does it really come with any disadvantages ompared to plain old pull? Only thing I can see or think of is that the precise chronology of events is a little muddled when looking at a --graph --pretty=oneline log, but 99% of the time I don't care about that, and I don't think the rest of my team does either. If there's no real disadvantage I'll just set it in /etc/gitconfig and keep silent :v:

(edit) Sidenote, I'm not really seeing any reason for our team not to just stick to cloning off of /var/git/projectnamehere.git and pushing/fetching from that, either. It's only 4 of us and it's more maintenance than active development nowadays, anyway.

Ciaphas fucked around with this message at 01:17 on Mar 23, 2016

# ¿ Mar 23, 2016 01:04

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Is it possible, in Clearcase, to have a config spec line that gives me the absolute most recent version of a file no matter what branch it's on? I've tried element * .../LATEST and element * LATEST to no avail so far.

# ¿ Apr 1, 2016 19:19

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Right now I have our dependency projects (two of them in our case, a custom Lua build and an internal math library) as two separate repos and anyone who wants to clone our main project just has to clone those too. After reading about the idiosyncracies of submodules, and knowing the training level of our team on Git, I have no will to change this :v:

# ¿ Apr 20, 2016 23:18

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Is there any particularly compelling reason not to --prune every time I do a git fetch? I want to start teaching my crew how to start using and sharing branches other than master for un-blessed work but not if they're eventually gonna bug me about cruft getting left behind. (They're still rather struggling with the concept of everyone having their own repos to work in, rather than the shared ClearCase vob of olde)

On the same note I know 1.8.something added a config to always prune on fetch, but we're stuck on git 1.7.10 because gently caress video games I guess. Any recourse besides a, I dunno, git pfetch and git ppull alias set?

# ¿ May 3, 2016 15:44

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Ciaphas posted:

Is there any particularly compelling reason not to --prune every time I do a git fetch? I want to start teaching my crew how to start using and sharing branches other than master for un-blessed work but not if they're eventually gonna bug me about cruft getting left behind. (They're still rather struggling with the concept of everyone having their own repos to work in, rather than the shared ClearCase vob of olde)

On the same note I know 1.8.something added a config to always prune on fetch, but we're stuck on git 1.7.10 because gently caress video games I guess. Any recourse besides a, I dunno, git pfetch and git ppull alias set?

Still wondering this, and have a followup question. Someone pushed a couple of commits up to our central repo with the wrong email address (the default, basically, because they forgot to configure it on their new system). If I use filter-branch or whatever to try to fix that on the central, is that going to mess up everyone who's already pulled down the new commits (like rebasing a pushed branch would)?

# ¿ May 5, 2016 20:03

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Thanks. shortlog (and OCD) was the only reason I really cared so I'll jus tset up a mailmap.

# ¿ May 6, 2016 01:24

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

In Git, say I were to push one of my branches up to origin for others in my team to look at, via git push origin ovm_optimize. When they're done looking at it, should I then delete it on origin via git push origin :ovm_optimize, or does it really not matter at all/depends on my team policy (which I'm pretty much making up as I go along anyway)?

For that matter, is there a nicer way to delete a remote branch than that? I understand what it means and why it works, it just looks doofy :v:

(ed: I guess I could write an alias, huh)

# ¿ Jun 4, 2016 00:28

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Stringent posted:

I'm not familiar with that colon syntax, what is it?

The manual just says to do this:
code:
git push origin --delete ova_optimize

It's what I was taught from the git book--read as "take nothing and overwrite the remote's branch called ovm_optimize with it". Like I said, kinda doofy!

Guess they must have added --delete in a later revision.

# ¿ Jun 4, 2016 02:49

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

We've got updated books at work now and, yeah, they both mention the colon delete syntax as historical footnotes. The one I was referencing appears to have been written with 1.6.1 in mind.

Still kinda wracking my brain on what sort of policy to set with our team re: pushing and deleting topic branches to central: whether to push them at all, whether to delete them, whether to rebase onto master and fast forward when done or always merge with --no-ff, etc. Being the CM guy is hard even on a small team of four :saddowns:

# ¿ Jun 9, 2016 01:01

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

I lean toward rebasing, personally, but the boss of my team is a little squirmy on the idea of :airquote:

losing history in that manner. Part of the clearcase background, I guess, where history is nearly immutable (and branches are totally different concepts, eugh).

# ¿ Jun 9, 2016 22:23

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

I do compile checks at most when a git conflict crops up, but that's mostly because in our shop and the way our databases are structured going back to past versions of the software is a bit of a fool's errand anyway.

# ¿ Jun 10, 2016 20:37

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Commits still hang around even if no branches point to them or their children, at least until the next time git decides its time to garbage-collect (or you do it manually)

For the most part to find an orphan before it gets garbage collected and deleted forever you need the reflog or some serious digging through the .git structure (if there's a command to just find all orphans I don't know it)

# ¿ Jul 28, 2016 21:50

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

I'm usually pretty good at reading DAGs and the Git version trees and I still have to go to the man page every time I think about using git rebase --onto :saddowns:

# ¿ Jul 29, 2016 19:12

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Series DD Funding posted:

Except for branch pointers or doing something really horrible with the plumbing commands, git does not have history editing either

Isn't history-editing basically what things like rebase, cherry-pick, and hell, amend are? Or are we on a definition of "history editing" I'm not cognizant of

# ¿ Aug 18, 2016 20:14

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Plorkyeran posted:

Rebase etc. create a new history and point the branch to that, but the old one is still there.

Ah, ok, didn't occur to me they were speaking in that sense. (e: and fair enough about cherry-pick, it's early and i wasn't thinking)

also i used clearcase for 8 years here and only just got our org to move off of it onto something else, it is now my trigger word

Ciaphas fucked around with this message at 20:38 on Aug 18, 2016

# ¿ Aug 18, 2016 20:34

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

To be fair if my choices were clearcase or nothing I'd...

well, I'd choose clearcase but I'd think about it for a long time, I promise that much

# ¿ Aug 19, 2016 18:41

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

There's nothing wrong with your branch being ahead of master, unless you're like gonna get an F on the assignment for that or something. Worst case you can just pull your branch, resolve conflicts, then start the list over from 1 if you really want the last commit on your branch to be before your last (merge) commit on master.

# ¿ Aug 30, 2016 00:14

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Data Graham posted:

Just git pull, like it suggests?

That's normally no problem, just means someone else has checked something into master while you were working on it. Happens more often than not.

It reads more like somehow Snak's origin/yourbranch got ahead of his local yourbranch, rather than master. Dunno how that happened, assuming no one else is supposed to be touching it.

# ¿ Aug 30, 2016 00:16

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Pretty much. The golden rule with rebases is to never ever ever rebase (or otherwise modify history) anything you've shared out. It's fine for pulling.

In fact, there's a command line argument and a config option to make git pull do a rebase instead of a merge. Easy enough to do manually, though, via git fetch <remote> then, if your local branch is checked out, git rebase <remote>/<branch>

# ¿ Sep 1, 2016 23:11

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

I'm trying to think of instances where git pull --rebase would gently caress up or be the wrong answer, and I'm coming up empty. Unless you're in a group that wants every merge commit for 100% true to life history, and nuts to that.

# ¿ Sep 1, 2016 23:27

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Yeah usually if I'm not 100% sure of what the history on all ends looks like I'll just fetch and either merge, rebase, or do nothing as required (headless checkout is fine if I'm just reviewing), so I haven't run into that edge case yet.

# ¿ Sep 1, 2016 23:49

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

In git is there a canonical way to update a commit message if it's already been pushed? My tactic so far has been to tsk at the the individual responsible (when it's not me :v:

) then tell them to revert the commit, revert the revert (using the commit message they actually wanted), then push those results.

(We're required to put work order numbers in the summary, and I haven't gotten a trigger to check for that fully working yet.)

Ciaphas fucked around with this message at 23:42 on Feb 14, 2017

# ¿ Feb 14, 2017 23:35

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

I've been moved to a team that--for reasons not in our control--uses TFS 2010 with TFVC. So I'm having to learn best practices there until some future point where we can upgrade TFS to at least 2013 and consider using Git for VC.

Right now we each have our own development branch (Development-Ciaphas for example), and Main. When we want to merge to Main, we:

-Merge from Main to our branch, resolving conflicts
-Check in, using some suitably pithy checkin comment like "Merge from Main"
-Merge from our branch to Main (should be 0 conflicts)
-Check in using another pithy comment

So my questions:

1) Do we need to do Get Latest at any point in those steps?
2) Is this even remotely like a best practice for a small team of 4 developers?
3) I don't know my way around the TFS gui in Visual Studio. When I look at the checkin history on Main, I just end up with a lot of "Merge from Development-XXX" checkins. How do I trail this back to the relevant checkins in the relevant branches?

# ¿ Aug 25, 2017 20:23

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 13:10

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

New Yorp New Yorp posted:

1) It's always a good idea to get latest before you do any merging operations. I swear it doesn't matter but I've heard enough people complain about bad merges that I'll assume it does.
2) Yeah, that's fine . You should be reverse integrating changes from Main on a regular basis, though.
3) In 2010? Nope. Better branch visualization was added later on but I doubt it's supported in TFS 2010.

TFS 2010 was EOLed several years ago and is unsupported. Getting to a modern version is going to suck for you guys. You'll have to do 2010 -> 2012, then 2012 should upgrade cleanly all the way to 2017. But 2012 doesn't support modern SQL server versions and 2017 only supports modern SQL server versions. There is zero reason to upgrade to anything other than the latest since the downtime and complexity of upgrading is going to be roughly the same whether you're going from 2010 to 2013 or 2010 to 2017. Among other things, TFS upgrades are one of the things I do professionally (albeit rarely).

Get upgraded to 2017 Update 2 as soon as possible and import it to VS Team Services and never have to deal with upgrade pain again. Seriously. Or if you're not using the work item tracking stuff, just use Git-TFS to convert the TFVC repo to a Git repo and shove that into VSTS.

We're early enough in the project that simply taking a current snapshot of the solution and wholesaling it over to a new/updated VC package isn't wholly incorrigible to the team leads/management. So we may just uninstall 2010 entirely and install 2017 on top, if it comes to that (we're on VS2015 but the main stakeholders all have MSDN licenses so VS2017 shouldn't be long in coming).

The network in question is air-gapped off of the internet for security though, and for the same reason getting approval for software upgrades is a pain in the rear end, so it might take a while, and VS Team Services is obviously OBE

Ciaphas fucked around with this message at 20:49 on Aug 25, 2017

# ¿ Aug 25, 2017 20:47

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Version Control Questions Megathread (SVN / git / whatever else)

«‹›2 »