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)

«‹›100 »

uXs: May 3, 2005; Mark it zero!

Guys, guys, the answer is obviously hg. Much better than git on Windows machines.

# ? Nov 7, 2013 20:18

Adbot: ADBOT LOVES YOU

# ? May 12, 2024 17:50

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

uXs posted:

Guys, guys, the answer is obviously hg. Much better than git on Windows machines.

How do they compare? I'm using hg on one project, but that's basically me making feature branches as a subcontractor and then filing pull requests, so I haven't used anymore detailed work flows.

# ? Nov 7, 2013 20:28

wwb: Aug 17, 2004

SCM-wise HG is generally on par with git and arguably better in many ways that you tend to run into for projects short of maintaining the linux kernel. Client-app-wise, the command line options are vastly more approachable to begin with. TortoiseHG is arguably better than TortoiseSVN or any existing git client on windows*. For closed-source stuff bitbucket's model is generally superior to github's; feature-wise both are on par and perhaps bitbucket is ahead as they support both git and hg. Outside of "git is what the cool kids are using" there is very little reason to pick git over HG in 2013.

*sorucetree is coming on pretty strong here. It will likely pick up HG capabilities soon too.

# ? Nov 7, 2013 22:26

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

No Safe Word: Feb 26, 2005

TFS being down right now is crippling as poo poo for our team and I'm angry that we use TFS when we did have git up and running (but due to the fact that we're actually Microsoft partners and at the time the TFS + git option didn't exist, we swapped).

Yes, TFS is "easier" but it really has been a huge drain on our team (which knows git already) as a whole, so I'll go the other way than the above posters and say if your team can handle git, use it and not TFS.

# ? Nov 8, 2013 17:24

Quebec Bagnet: Apr 28, 2009; mess with the honk
you get the bonk; Lipstick Apathy

You do know you can host TFS yourself, right?

# ? Nov 8, 2013 17:32

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

No Safe Word posted:

TFS being down right now is crippling as poo poo for our team and I'm angry that we use TFS when we did have git up and running (but due to the fact that we're actually Microsoft partners and at the time the TFS + git option didn't exist, we swapped).

Yes, TFS is "easier" but it really has been a huge drain on our team (which knows git already) as a whole, so I'll go the other way than the above posters and say if your team can handle git, use it and not TFS.

Yeah, that's pretty bad, but it's not like Github never has downtime. And TFS Express is hosted on-prem, anyway, so if it goes down it's your own fault.

# ? Nov 8, 2013 17:33

uXs: May 3, 2005; Mark it zero!

Then again, with a distributed system there's nothing to go down. If all else fails you can still bundle changesets and put them on a USB drive.

# ? Nov 8, 2013 17:36

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

I can't believe people actually use hosted version control

# ? Nov 8, 2013 17:37

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Ithaqua posted:

Yeah, that's pretty bad, but it's not like Github never has downtime.

Even if GitHub goes down, I can still work. I can still pull somebody's remote branch if they want me to test something.

# ? Nov 8, 2013 18:06

Knyteguy: Jul 6, 2005; YES to love
NO to shirts; Toilet Rascal

No Safe Word posted:

TFS being down right now is crippling as poo poo for our team and I'm angry that we use TFS when we did have git up and running (but due to the fact that we're actually Microsoft partners and at the time the TFS + git option didn't exist, we swapped).

Yes, TFS is "easier" but it really has been a huge drain on our team (which knows git already) as a whole, so I'll go the other way than the above posters and say if your team can handle git, use it and not TFS.

Same problem here. It's incredibly irritating (and I was actually working on a pretty fun/creative project for once).

quote:

I can't believe people actually use hosted version control

My employer chose what we (I) use. I was pretty comfortable with Git before this job. The GUI for TFS within Visual Studio is nice though, and in the 7 months I've worked with TFS this is the first time it's really been a problem. But yea it sucks because there's a trade show next week where we're showing off our product, and I'm really uncomfortable putting too much effort in without live version control.

# ? Nov 8, 2013 18:11

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Suspicious Dish posted:

Even if GitHub goes down, I can still work. I can still pull somebody's remote branch if they want me to test something.

Local workspaces solve that, if you're using VS2012.

# ? Nov 8, 2013 18:12

Knyteguy: Jul 6, 2005; YES to love
NO to shirts; Toilet Rascal

Ithaqua posted:

Local workspaces solve that, if you're using VS2012.

Hey local workspaces are a real luxury. Nah but really, every time I've switched to a local workspace I end up getting corrupted data that destroys at least a days worth of productivity. It probably had to do with the last hard drive in my work machine failing rapdily, but I'm a little nervous to try it again. Maybe when we switch to Windows 8.1 / VS 2013.

# ? Nov 8, 2013 18:16

No Safe Word: Feb 26, 2005

i barely GNU her! posted:

You do know you can host TFS yourself, right?

That doesn't make it not-centralized and suddenly immune to a centralized system causing a team-wide outage of their source control capabilities.

Ithaqua posted:

Local workspaces solve that, if you're using VS2012.

Hmm, I'll have to look into that (otherwise my retort would have been the same as Suspicious Dish). We actually resorted to sneakernet'ing some changes that needed to be immediately integrated between me and another team member.

# ? Nov 8, 2013 18:44

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

No Safe Word posted:

That doesn't make it not-centralized and suddenly immune to a centralized system causing a team-wide outage of their source control capabilities.

Hmm, I'll have to look into that (otherwise my retort would have been the same as Suspicious Dish). We actually resorted to sneakernet'ing some changes that needed to be immediately integrated between me and another team member.

Well, local workspaces won't save you if you're trying to access something that's on another person's machine. They just keep you from having to deal with everything being un-check-outable because you can't communicate to a server.

# ? Nov 8, 2013 20:48

wwb: Aug 17, 2004

rotor posted:

I can't believe people actually use hosted version control

Didn't we have this debate a few pages ago. Anyhow, that is a strong statement, care to back it up?

# ? Nov 8, 2013 23:44

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

wwb posted:

Didn't we have this debate a few pages ago. Anyhow, that is a strong statement, care to back it up?

just my opinion, and I guess for non- engineering orgs where software is not what you sell or on any critical paths or whatever it's not a big deal.

but yeah for the rest, I don't think you should be allowing a third party to control your release process. Big Steve's Repo Hut dot com getting ddosed should not mean that you can't continue to work or release as usual.

then there's the potential security issues, and the fact that running your own repo is stupidly easy, makes the ROI on the whole thing completely upside down imo

# ? Nov 9, 2013 00:10

wwb: Aug 17, 2004

I do agree with the point for an engineering organization or at least some place generating their own IP. That said, at least here in the US the legal protections for someone pulling something with your rented storage space are very strong at the end of the day so I wouldn't be too hung up on that.

For the rest I see where you are coming from but my general experience is that outages from your big cloud SCM providers (github / bitbucket ) are about as frequent as the outages one will see with an on-premises installation of anything. Especially if you account for parts of the dev team perhaps not being on premises so you are fundamentally as reliable as the premises' ISP.

Finally, putting my credit card down for a 25 person bitbucket account ($25/mo) has been fundamentally more stupidly easy than:

* standing up a new server to host all the HG / HG web bits
* continually caring and feeding for that server in terms of disk space needs, patching both the HG stack and the underlying OS and all the other stuff that needs being done
* being the guy who is taking the call when something doesn't work weather it be my fault or God's fault.

# ? Nov 9, 2013 01:00

uXs: May 3, 2005; Mark it zero!

I set up the HG server at work. Extra work after it was set up: none whatsoever. Disk space used: extremely low.

And that's with 400+ repositories on it.

The only thing that worries me is that I forgot how to set it up and that the HG installation is getting out of date.

# ? Nov 9, 2013 09:40

aerique: Jul 16, 2008

uXs posted:

I set up the HG server at work. Extra work after it was set up: none whatsoever. Disk space used: extremely low.

And that's with 400+ repositories on it.

The only thing that worries me is that I forgot how to set it up and that the HG installation is getting out of date.

Well, that's the whole point the previous poster was making. Also what if the server croaks with a deadline looming? Is it backed up off-site and is that your job / responsibility?

# ? Nov 9, 2013 10:38

uXs: May 3, 2005; Mark it zero!

aerique posted:

Well, that's the whole point the previous poster was making. Also what if the server croaks with a deadline looming? Is it backed up off-site and is that your job / responsibility?

True.

Backups are made, but not my job. Also since it's distributed, backups are on people's PC's anyway.

# ? Nov 9, 2013 10:45

wwb: Aug 17, 2004

uXs posted:

I set up the HG server at work. Extra work after it was set up: none whatsoever. Disk space used: extremely low.

And that's with 400+ repositories on it.

The only thing that worries me is that I forgot how to set it up and that the HG installation is getting out of date.

quote:

Backups are made, but not my job. Also since it's distributed, backups are on people's PC's anyway.

Unfortunately I'm managing the IT side of the shop so I can't skip backups and updates with a straight face. It isn't a whole lot of work -- our on premises SVN repos are not a whole lot of hassle either. Except if in the event they crash hard. We are anal enough to backup bitbucket as well -- using a 30 line python script.

On the flip side the cloud provider, when combined with CI, has made it easy enough that we have been able to do code edits from an iPhone and push them out to the live site.

# ? Nov 9, 2013 16:12

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

setting up a version control machine and ensuring proper backups are made is trivial.

i just think the dev process needs to be self-contained.

# ? Nov 9, 2013 22:45

Hughlander: May 11, 2005

rotor posted:

setting up a version control machine and ensuring proper backups are made is trivial.

i just think the dev process needs to be self-contained.

Fortunately you can get peanut butter in your chocalate. The whole point of distributed version control is to not be hierarchical. Have your internal sever as a remote. Have your github account as a remote. Fetch both and push both.

# ? Nov 10, 2013 04:09

No Safe Word: Feb 26, 2005

No Safe Word posted:

TFS being down right now is crippling as poo poo for our team and I'm angry that we use TFS

This again, 5 days later, and it's not 100% down but it's slow enough to be just as bad. And I'll stop bashing TFS now.

:mad:

# ? Nov 13, 2013 21:16

brathering: Sep 26, 2007; ducky ducky duck duck

Theres no need for TFS ever

Use git like everyone else does

# ? Nov 13, 2013 21:25

No Safe Word: Feb 26, 2005

brathering posted:

Theres no need for TFS ever

Use git like everyone else does

No Safe Word posted:

we did have git up and running (but due to the fact that we're actually Microsoft partners and at the time the TFS + git option didn't exist, we swapped).

Believe me, I know

# ? Nov 13, 2013 21:43

brathering: Sep 26, 2007; ducky ducky duck duck

I dont like any part of tfs, you could choose a great issue tracker and a build server and combine them with git, no problem.

# ? Nov 13, 2013 22:10

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

brathering posted:

I dont like any part of tfs, you could choose a great issue tracker and a build server and combine them with git, no problem.

This is why I hate monolithic software products.

I mean, really, what are the chances that one company is going to make the best issue tracker, build server, vcs, etc?

# ? Nov 13, 2013 23:30

raminasi: Jan 25, 2005; a last drink with no ice

I want my git repository to have a particular "default" config file that is never actually has changes to it pushed anywhere by anyone. I think that git update-index --assume-unchanged path/to/file.txt is what I want, but will this make it so that the file is assumed unchanged by everyone who grabs it, rather than just by me on my machine? I'm having trouble asking this question clearly.

# ? Nov 13, 2013 23:32

Strong Sauce: Jul 2, 2003; You know I am not really your father.

GrumpyDoctor posted:

I want my git repository to have a particular "default" config file that is never actually has changes to it pushed anywhere by anyone. I think that git update-index --assume-unchanged path/to/file.txt is what I want, but will this make it so that the file is assumed unchanged by everyone who grabs it, rather than just by me on my machine? I'm having trouble asking this question clearly.

Why can't you just use .gitignore? Or are there restrictions you want placed directly on the file?

# ? Nov 13, 2013 23:45

raminasi: Jan 25, 2005; a last drink with no ice

Strong Sauce posted:

Why can't you just use .gitignore? Or are there restrictions you want placed directly on the file?

I want the base version in the repo. I just don't want any changes to it to be tracked anywhere. Is there some way I can use .gitignore for this? Force-adding it still results in changes being tracked.

# ? Nov 14, 2013 00:07

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

In that case use --assume-unchanged.

# ? Nov 14, 2013 00:13

Ashex: Jun 25, 2007; These pipes are cleeeean!!!

Git keeps biting me when it comes to CRLF, I've been using a .gitattributes files to manage it but I didn't add pngs to it and now I've got a bunch of images files in the repo that are invalid.

Is there a way to recommit these files? Locally they're fine so I just need to push them back up.

# ? Nov 14, 2013 01:00

Lysidas: Jul 26, 2002; John Diefenbaker is a madman who thinks he's John Diefenbaker.; Pillbug

GrumpyDoctor posted:

I want the base version in the repo. I just don't want any changes to it to be tracked anywhere. Is there some way I can use .gitignore for this? Force-adding it still results in changes being tracked.

Don't do this. It only leads to pain in the long run.

Create a settings override mechanism and ignore the override file. I worked on a Django app a little while ago, and the last part of settings.py was

Python code:

# Keep this as the last section of this file:
try:
    from settings_override import *
except ImportError:
    # Don't care. No override settings are present.
    pass

settings_override.py was listed in the appropriate .gitignore.

# ? Nov 14, 2013 01:44

raminasi: Jan 25, 2005; a last drink with no ice

Lysidas posted:

Don't do this. It only leads to pain in the long run.

Create a settings override mechanism and ignore the override file.

Hm. I appreciate the advice, but I'm not sure how I can accomplish this using Visual Studio user property sheets, because I don't actually control how the .props files are used. I'll give it some thought.

# ? Nov 14, 2013 15:28

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

The direct equivalent of that would be <Import Project="$(MSBuildThisFileDirectory)userconfig\*.props" /> in your default config property sheet.

Visual Studio also lets you add fields to the project settings dialog with defaults and user-specific values that don't get committed. If it's a viable option for your setup, it's usually the best choice. The end result looks like this:

# ? Nov 14, 2013 16:26

o.m. 94: Nov 23, 2009

Something that confuses me about git; it is my understanding that commits are essentially discrete 'objects', and in normal usage, since you are on a branch, doing a commit adds the commit to the branch "tree". If one was to be in a headless state, such as deploying a tag, one could make a commit and it would exist in the repository, but since you aren't on a branch, it's not linked anywhere and so the commit can be hard to find, although it's still there.

Now, say I am on a live server which is in a headless state because a tag has been checked out. I want to deploy a new tag, and start by fetching new commits. These new commits aren't merged into any branch locally yet, but that's cool because I just want to jump to a new tag anyway without hopping into an actual branch.

How is it that when I check out my new tag, git knows which commits to change my local files, when they haven't yet been merged? The commit ref is just pointing to one commit, that commit doesn't know which commits to link to, because I assume that information is stored in the branch, and not the commit?

Does this make any sense? Why does creating a tag from a branch and deploying that tag without any merging know what commit "path" to follow? I thought they were just references to particular, stand-alone commits and not a branch.

# ? Nov 14, 2013 16:32

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

I don't entirely understand your question, but you appear to have a very incorrect mental model of git that is leading to confusion.

Branches are just pointers to commits that are changed when you make a new commit with that branch active, while tags are pointers to commits which do not automatically get changed. Branches and tags store no information other than this pointer. Commits themselves are a full snapshot of all of the files, with pointers to one or more parent commits (or zero for the root commit). Checking out a new tag (or an arbitrary commit) is conceptually equivalent to just deleting all of the files tracked by git for the current commit, and then creating new copies of all of the files in the new commit in the working directory, but obviously it optimizes this a lot.

# ? Nov 14, 2013 16:46

Adbot: ADBOT LOVES YOU

# ? May 12, 2024 17:50

Vanadium: Jan 8, 2005

Each commit knows it parent(s). Given a commit you can always follow the ancestry chain upwards.

# ? Nov 14, 2013 17:36

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

«‹›100 »