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 »

RyanNotBrian: Nov 28, 2005; Always five, acting as one. Dedicated! Inseparable! Invincible!

Hi all, another git newbie here.

I'm trying to plan an architecture for using git across a small team of web developers. I've worked with SVN before, but never set up a shared git repo.

This is the environment I'm thinking of:
Each developer has a LOCAL machine
We all share an internal STAGING server
Our web sites are hosting on a PRODUCTION server at our data center

LOCAL machines have Apache, MySQL, git as well as whatever development tools the developers need
STAGING has Apache, MySQL as well as Gitolite
PRODUCTION is running Apache and MySQL, but not git(?). We have FTP access to this machine.

This is how I see the workflow happening:
When a new project starts development a team leader create a new git repo on STAGING
The developers working on it pull it down to PRODUCTION and start working
Developer can commit changes locally. At key times the will commit and then push their latest work (or a stable branch of it) to STAGING for others to view or pull down.
Internal testing happens on STAGING
Once the site is done and tested we run a process to push the site from STAGING to PRODUCTION
If the client ever needs an update we follow the same procedure, and the final process just pushes the changed files from STAGING to PRODUCTION

So my questions are:
- Does the above make sense? Is it a fairly standard way to run a web shop or am I doing something strange.

- Should I be running git on my PRODUCTION server as well and use that to push changes live? Or is this last step commonly done with FTP.

- Are there tools that work with git that can FTP only the changed files from STAGING to PRODUCTION?

- We use Eclipse as an IDE. I've played with eGit and it keeps complaining that I shouldn't have my .git repository inside my project directory. Am I doing something wrong? Is there a better tool that integrates with Eclipse? Or do people generally stick to the command line and shun the IDE tools.

- Is Gitolite the best tool to share a repo like this? I started using Gitosis but then realised it's been abandoned.

Thanks

# ? Sep 5, 2011 08:32

Adbot: ADBOT LOVES YOU

# ? May 11, 2024 22:09

Profane Obituary!: May 19, 2009; This Motherfucker is Dead

RyanNotBrian posted:

Hi all, another git newbie here.

I'm trying to plan an architecture for using git across a small team of web developers. I've worked with SVN before, but never set up a shared git repo.

This is the environment I'm thinking of:
Each developer has a LOCAL machine
We all share an internal STAGING server
Our web sites are hosting on a PRODUCTION server at our data center

LOCAL machines have Apache, MySQL, git as well as whatever development tools the developers need
STAGING has Apache, MySQL as well as Gitolite
PRODUCTION is running Apache and MySQL, but not git(?). We have FTP access to this machine.

This is how I see the workflow happening:
When a new project starts development a team leader create a new git repo on STAGING
The developers working on it pull it down to PRODUCTION and start working
Developer can commit changes locally. At key times the will commit and then push their latest work (or a stable branch of it) to STAGING for others to view or pull down.
Internal testing happens on STAGING
Once the site is done and tested we run a process to push the site from STAGING to PRODUCTION
If the client ever needs an update we follow the same procedure, and the final process just pushes the changed files from STAGING to PRODUCTION

So my questions are:
- Does the above make sense? Is it a fairly standard way to run a web shop or am I doing something strange.

- Should I be running git on my PRODUCTION server as well and use that to push changes live? Or is this last step commonly done with FTP.

- Are there tools that work with git that can FTP only the changed files from STAGING to PRODUCTION?

- We use Eclipse as an IDE. I've played with eGit and it keeps complaining that I shouldn't have my .git repository inside my project directory. Am I doing something wrong? Is there a better tool that integrates with Eclipse? Or do people generally stick to the command line and shun the IDE tools.

- Is Gitolite the best tool to share a repo like this? I started using Gitosis but then realised it's been abandoned.

Thanks

While I don't have a comment on the rest, I decided against hosting my own git repo's and just pay Github for private repo's. It acts as a backup, a centralized location, and a really nice online viewer all in one.

# ? Sep 5, 2011 15:56

ToxicFrog: Apr 26, 2008

RyanNotBrian posted:

- Are there tools that work with git that can FTP only the changed files from STAGING to PRODUCTION?

If you're rolling your own you can use git diff --name-only old..new to find out which files changed between commits old and new.

However, a better solution is to have a PRODUCTION that you can access via ssh rather than ftp and use something like rsync, which automatically transfers only changed files.

# ? Sep 5, 2011 16:40

good jovi: Dec 11, 2000; 'm pro-dickgirl, and I VOTE!

RyanNotBrian posted:

So my questions are:
- Does the above make sense? Is it a fairly standard way to run a web shop or am I doing something strange.

- Should I be running git on my PRODUCTION server as well and use that to push changes live? Or is this last step commonly done with FTP.

- Are there tools that work with git that can FTP only the changed files from STAGING to PRODUCTION?

I think you're unnecessarily conflating source control and deployment. I've heard of people doing things like this, pushing to repos on the web server, but I've never done it and it doesn't sound like a very good way to do it.

Just set up one repo somewhere (ie a private github repo) and store your stuff there. Then let deploy tools (you're using Java, right? use whatever capistrano equivalent you prefer) do the deploying.

# ? Sep 5, 2011 17:37

stray: Jun 28, 2005; "It's a jet pack, Michael. What could possibly go wrong?"

Ziir posted:

I just started using Git and I'm really not sure what I'm doing. Say I edit a file and want to commit the changes, if I type "git commit -m 'comments'" then it tells me that there were no changes to commit and suggests that I do "git add file" first and then commit. This doesn't make sense to me because I already added that file before, and I don't feel like I should have to re-add the file again just because I edited it.

Am I missing something here?

You have to stage your changes before committing them. Yes, every time. This is what allows a Git user to separate her commits into discrete, related changes and avoids the problem of "Look at all this stuff I changed! Good luck sussing out how those changes relate to one another!" commits.

Plorkyeran posted:

when actually writing code I almost exclusively use -am with a <5 word commit message then before pushing review each commit, squash and split like crazy, and add actual commit messages

I've strongly considered trying to figure out a way to just autocommit every time I save a file so that I can completely forget about dicking around with source control while coding

When you do, let us know, because I want to make a note to never fork any of your code. You are trying to find a way to avoid one of Git's biggest and best features, while also ensuring that no one will ever be able to comprehend your commit history. (E: nm)

RyanNotBrian posted:

(setting up shared git repo)

I have to agree with Profane Obituary: Github makes this absolutely brain-dead easy. It's totally worth ponying up for private repos and not very expensive at all (though I do wish they'd offer annual plans).

Oh, and in that Git for Ages 4 and Up, he's using git-achievements to generates that achievement. I just installed it and it seems like fun. Here are my achievements.

stray fucked around with this message at 18:51 on Sep 7, 2011

# ? Sep 5, 2011 22:59

RyanNotBrian: Nov 28, 2005; Always five, acting as one. Dedicated! Inseparable! Invincible!

stray posted:

I have to agree with Profane Obituary: Github makes this absolutely brain-dead easy. It's totally worth ponying up for private repos and not very expensive at all (though I do wish they'd offer annual plans).

Thanks for the advice folks.

We currently have SVN repos on Assembla that work pretty well, the annual fee is not too bad. I wanted to move to an in-house server for a few reasons:
- We are in Australia so big network operations take some time
- We wanted a VCS that will integrate with our tickets in Redmine

The network speed issue may not be an issue with git, as I understand there is much less traffic going back and forth after the initial clone. Has anyone had experience integrating either Github or Assembla repos with Redmine?

edit:
This looks interesting! http://eddieringle.com/easily-integrate-a-github-repository-with-redmine-using-the-github-hook-plugin/

RyanNotBrian fucked around with this message at 00:07 on Sep 6, 2011

# ? Sep 6, 2011 00:04

Karanth: Dec 25, 2003; I need to finish Xenogears sometime, damn it.

stray posted:

When you do, let us know, because I want to make a note to never fork any of your code. You are trying to find a way to avoid one of Git's biggest and best features, while also ensuring that no one will ever be able to comprehend your commit history.

I think you missed this part:

Plorkyeran posted:

then before pushing review each commit, squash and split like crazy, and add actual commit messages

The commit history you see would be clean, well documented, precise changes.

# ? Sep 6, 2011 02:40

djmycroft: Sep 27, 2002

Plorkyeran posted:

I've strongly considered trying to figure out a way to just autocommit every time I save a file so that I can completely forget about dicking around with source control while coding

I use mercurial, and set up emacs to make a new patch in the mercurial queue every time I save a file. The fact that it's a mercurial queue patch means that I can't accidentally push them until I arrange them until genuine commits. It actually works really well for me.

# ? Sep 6, 2011 08:04

Profane Obituary!: May 19, 2009; This Motherfucker is Dead

RyanNotBrian posted:

Thanks for the advice folks.

We currently have SVN repos on Assembla that work pretty well, the annual fee is not too bad. I wanted to move to an in-house server for a few reasons:
- We are in Australia so big network operations take some time

The network speed issue may not be an issue with git, as I understand there is much less traffic going back and forth after the initial clone. Has anyone had experience integrating either Github or Assembla repos with Redmine?

I can't speak to the redmine integration (I normally just keep everything issues, pull requests etc in Github). But as for network operations the only time git actually uses the network is when it actually needs to. A clone makes just that, a clone or mirror of the entire remote repo locally on your hard disk. Any commits you make will be made to that local repository. Then when you are ready, you push your changes to github, and then other people can pull them.

Basically the only operations that actually hit the network are clone, pull (fetch technically), and push.

# ? Sep 6, 2011 12:38

Doc Hawkins: Jun 15, 2010; Dashing? But I'm not even moving!

Sailor_Spoon posted:

I think you're unnecessarily conflating source control and deployment. I've heard of people doing things like this, pushing to repos on the web server, but I've never done it and it doesn't sound like a very good way to do it.

As I understand it, it's a pretty common part of Continuous Integration setups. I know it's how Heroku does things.

What part of the idea bothers you?

# ? Sep 6, 2011 21:05

good jovi: Dec 11, 2000; 'm pro-dickgirl, and I VOTE!

Doc Hawkins posted:

As I understand it, it's a pretty common part of Continuous Integration setups. I know it's how Heroku does things.

What part of the idea bothers you?

For things like that, you typically have hooks on the remote repo to run the deploy. What RyanNotBrian is describing sounds too much like "to deploy, just ssh into the server and run 'svn up'", a pattern best avoided.

# ? Sep 6, 2011 21:26

Mithaldu: Sep 25, 2007; Let's cuddle.

Sailor_Spoon posted:

For things like that, you typically have hooks on the remote repo to run the deploy. What RyanNotBrian is describing sounds too much like "to deploy, just ssh into the server and run 'svn up'", a pattern best avoided.

You should mention that it should be avoided because having checkouts on your web server might give attackers access to your code repo.

# ? Sep 6, 2011 21:27

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

Is there a term for "having part of your repository be mirrored on a completely different repository?" Specifically, I have a SVN repo with a bunch of code. Part of this code also needs to live on a different respository. The users of that repository won't be making any changes or anything; they only need read access, and they only really need snapshots of milestones, not every little change. They can't just use the main one because there's no way to get them access to it (it's a different company). Is there a more elegant way to do this than "export and commit to the other repo at every milestone?"

# ? Sep 7, 2011 19:50

wwb: Aug 17, 2004

No idea what to call it, but if the milestones hit a specified branch (copies are cheap) then you could use svn synch to mirror that branch pretty easily.

# ? Sep 7, 2011 20:03

Factor Mystic: Mar 20, 2006; Baby's First Post-Apocalyptic Fiction

Mithaldu posted:

You should mention that it should be avoided because having checkouts on your web server might give attackers access to your code repo.

This is what a coworker said when I suggested a 'deploy' branch but I don't understand what's so hard about not having your server serve files out of .git or .svn directories. It's not that hard.

# ? Sep 7, 2011 20:22

Mithaldu: Sep 25, 2007; Let's cuddle.

Factor Mystic posted:

This is what a coworker said when I suggested a 'deploy' branch but I don't understand what's so hard about not having your server serve files out of .git or .svn directories. It's not that hard.

Yeah, but what if i exploit your image thumbnailer to permit me read access to arbitrary paths on your system? (Just as an example.)

# ? Sep 7, 2011 20:28

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

Mithaldu posted:

Yeah, but what if i exploit your image thumbnailer to permit me read access to arbitrary paths on your system? (Just as an example.)

So what?

If you can read arbitrary paths, you can already access the source code. There's nothing extra to read from having read-only access to the repository.

# ? Sep 8, 2011 01:18

wins32767: Mar 16, 2007

He's saying arbitrary paths on the whole system. What about the password file?

# ? Sep 8, 2011 01:37

Mithaldu: Sep 25, 2007; Let's cuddle.

Janin posted:

So what?

If you can read arbitrary paths, you can already access the source code. There's nothing extra to read from having read-only access to the repository.

You don't have much practical experience with system intrusion, do you?

It gives me the urls of your source repo, which may be accessible on the internet, or at least proxied throught he server; as well as the login credentials, which may be read-only, but provide strong hints on how to brute-force the write creds; in either case, having read credentials at least gives me the whole history of the repo, as well as any other projects stored in there; and with git i don't even need any credentials because the history is right there; and who knows what nice extras like hastily reverted passwords the history contains...

Try thinking about what someone with determination AND creativity could do.

Leaving the security impact aside there's also the fact that a source checkout is not an atomic operation, the changes of it happen as git/svn/whatever touches the files, which, combined with ongoing user access can lead to interesting situations.

In short: Just don't loving do it, for any possible point as to how you could make it feasible i can give you two counters and even if i run out, you'd still have a huge massive list of poo poo to look out for that you can just avoid by not doing it.

# ? Sep 8, 2011 01:37

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

Mithaldu posted:

You don't have much practical experience with system intrusion, do you?

It gives me the urls of your source repo, which may be accessible on the internet, or at least proxied throught he server; as well as the login credentials, which may be read-only, but provide strong hints on how to brute-force the write creds; in either case, having read credentials at least gives me the whole history of the repo, as well as any other projects stored in there; and with git i don't even need any credentials because the history is right there; and who knows what nice extras like hastily reverted passwords the history contains...

So you're saying that somebody prone to gross stupidity might be doing tons of other stupid things. That makes sense, I guess. But there's nothing related to source checkouts in that argument. It's like saying you should obfuscate all the source code before copying it over, because a developer might have posted their credit card and DOB in the file header.

There's no reason to expose a source repo on the internet. There's no reason to let the webserver have any sort of credentials (just git/bzr/hg push to it). There's no reason why passwords should be stored in the history (they should be changed immediately, and the relevant history expunged).

Mithaldu posted:

Try thinking about what someone with determination AND creativity could do.

You're acting as if a source checkout is a horribly dangerous thing to have, when in reality it's right next to "broadcasting an IP address !!!" in terms of risk to your servers.

Mithaldu posted:

Leaving the security impact aside there's also the fact that a source checkout is not an atomic operation, the changes of it happen as git/svn/whatever touches the files, which, combined with ongoing user access can lead to interesting situations.

That depends on your VCS, and how you manage versions. Check out the new version, then set your webapp's live path to the checkout. Boom, atomic.

# ? Sep 8, 2011 04:00

wwb: Aug 17, 2004

The idiots I work with and my own stupidity are more of a danger to our operations than most hackers I can think of. Deploying backed by source control is a much better way to fly than not for us. YMMV.

# ? Sep 8, 2011 05:45

good jovi: Dec 11, 2000; 'm pro-dickgirl, and I VOTE!

wwb posted:

The idiots I work with and my own stupidity are more of a danger to our operations than most hackers I can think of. Deploying backed by source control is a much better way to fly than not for us. YMMV.

Well of course you should be "backed by source control", that's where the source is. Most of the projects I work on are set up to tag releases, so it's trivial to see what has been deployed where, and when. My point was really that deployment is usually more than just changing code. I've never personally worked on anything that was simple enough to deploy by updating a repo on the server. And if you think your project is, how much longer will that be true?

# ? Sep 8, 2011 05:55

Mithaldu: Sep 25, 2007; Let's cuddle.

Janin posted:

Not only do you ignore the existence of SVN, you also completely missed this point:

Mithaldu posted:

you'd still have a huge massive list of poo poo to look out for that you can just avoid by not doing it.

And last, but not least, you assume that all coders are excellent.

So, at this point trying to convince you is pointless since your world view is already massively divorced from reality.

# ? Sep 8, 2011 10:15

stray: Jun 28, 2005; "It's a jet pack, Michael. What could possibly go wrong?"

Hey, guess what? Github actually will let you pay annually! I submitted a support request asking about annual payments and got this back in return:

quote:

From: XXXXXXXXXXXXX (Support staff)
Subject: [Contact] Annual plans?

If you have already created a personal account, you can tell me the username and I will switch it to yearly payments.

If you don't have a personal account yet, please create it on the **FREE** plan first. Then tell me the username of the personal account and I will switch it to yearly payments. Finally, you can upgrade to the desired plan.

No discount, but I'd still rather pay them once a year than every month.

# ? Sep 9, 2011 19:05

Melraidin: Oct 11, 2005

I'm looking for suggestions on what sort of source control I should be using and how I should set up my projects. I've worked with Subversion a fair bit (and Sourcesafe, but we don't talk about that), along with a few minutes with Git.

I'd like to have one primary project where I do work meant to be shared between clients. I'd like to have many client projects that make use of the primary project for the most part. The client projects would each have some custom files though, some that may be intended to override the primary project's copy of the file, some that may not exist in the primary project at all.

Can anyone suggest what would be the most appropriate source control system for this? I'm guessing most systems would be fine with it. How about how to set these projects up? With Subversion I'd consider setting the shared files in each client project as externals pointing at the primary project but this feels like it'd involve some suck where the externals would have to be configured manually for each client project.

Is there a decent way to do what I'm looking for, ideally in a manner that would cause all client projects to automatically be updated with the newest versions of the shared files anytime I commit to the primary? I'm sure this update could be scripted in the end but it'd be nice if it were handled for me.

Or, alternatively, can you tell me why my ideas are stupid and what I should be doing instead?

# ? Sep 21, 2011 22:11

ColdPie: Jun 9, 2006

Melraidin posted:

I'm looking for suggestions on what sort of source control I should be using and how I should set up my projects. I've worked with Subversion a fair bit (and Sourcesafe, but we don't talk about that), along with a few minutes with Git.

I'd like to have one primary project where I do work meant to be shared between clients. I'd like to have many client projects that make use of the primary project for the most part. The client projects would each have some custom files though, some that may be intended to override the primary project's copy of the file, some that may not exist in the primary project at all.

Can anyone suggest what would be the most appropriate source control system for this? I'm guessing most systems would be fine with it. How about how to set these projects up? With Subversion I'd consider setting the shared files in each client project as externals pointing at the primary project but this feels like it'd involve some suck where the externals would have to be configured manually for each client project.

Is there a decent way to do what I'm looking for, ideally in a manner that would cause all client projects to automatically be updated with the newest versions of the shared files anytime I commit to the primary? I'm sure this update could be scripted in the end but it'd be nice if it were handled for me.

Or, alternatively, can you tell me why my ideas are stupid and what I should be doing instead?

Use Git.

There's a couple ways you could do this, depending on what you like.

If each client project needs to be coupled with a specific version/branch of your primary project, then Git submodules is the obvious tool. This is probably the route you want to take if your projects are going to grow to a size where verification and testing become important.

But if you're not going to bother with being rigorous, then you could just set up a repository for each client and one for the primary project and have your client project build systems refer to the external primary project. Then when you do a build, they will refer to whatever is in the primary project's working tree.

There's probably others, but these came to mind immediately.

# ? Sep 21, 2011 23:50

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

I'm trying to set up a git repository on Assembla (assembla.com) and I'm having trouble making my first "push". I'm fairly ignorant of git but I've previously successfully pushed to a repository on github. I'm using git on Windows Vista. When I run git bash from the relevant directory and type "git push", I get:

The authenticity of host 'git.assembla.com (64.250.188.42)' can't be established. RSA fingerprint is 31:06:...(omitted)...:07:e6. Are you sure you want to continue connecting (yes/no)?

Entering "yes" is no good, it doesn't accept the passphrase.

I know that this has something to do with SSH keys, but I can't figure out what might be wrong with mine. My git name and email on my local machine match up with the ones I've entered on Assembla, and I've tried generating a new SSH key and uploading the id_rsa.pub file to Assembla to no effect.

A search turned up this forum thread: http://forum.assembla.com/forums/3/topics/2754

As far as I can tell none of the suggestions raised by the administrator in the final post apply. 1 and 2 shouldn't apply because this is a vanilla account on the site and I haven't changed any settings. 3, 4 and 5 I believe I have done. 6 I have done, although I deleted the line "GSSAPIAuthentication" because it generated an additional error message.

Edit: I have found the cause after asking on Stack Overflow. The config file referenced my private key file when it should have referenced my public key file (or vice versa, I can't remember).

Hammerite fucked around with this message at 19:14 on Sep 24, 2011

# ? Sep 23, 2011 15:35

Modern Pragmatist: Aug 20, 2008

Is there any way to set rules for how hunks returned by git-diff are determined? I have figured out how to change the hunk header text but I can't figure out how/if you can change the actual hunk generation.

For example:

code:

@@-183,11 +320,45 @@ function res = pixelMask(self,dims)
    end

    function res = quantize(self,pixelResolution)
+       % quantize - rounds all interpolated points to the nearest pixel
+       % do stuff here
+    end
+
+   function res = doOtherShit(self)
+       % TODO: Complete
+   end

As you can see, the header refers to the function pixelMask, but this function doesn't actually have any differences. Additionally, there may be multiple functions contained within a single hunk

What I'm attempting to do is get a list of all functions within a file that were modified. Maybe there is an easier way.

# ? Sep 30, 2011 23:08

pseudorandom name: May 6, 2007

Abusing git's diff hunk header generation to figuring which functions were changed is a terrible idea, simply because git has no knowledge of the source language's syntax.

# ? Oct 1, 2011 00:53

Xik: Mar 10, 2011; Dinosaur Gum

Wasn't sure which question megathread to put this in; .NET, General or this one, I think it is more relevant to making source code public via version control so am going to ask it here.

I have a .NET C# form project using git for version control which uses a web API to pull data from. At the moment it requires an API key which should remain private. I am also currently in the process of switching the authentication over to OAuth, but I will have the same problem with the consumer secret.

The project source is public but I obviously need to include the API key/consumer secret somewhere.

I would like the source to remain easy to compile without too much effort from anyone else, but also have the API key/Consumer secret hard coded into binary releases.

If I put it in a config file to keep it out of the source I expose the key to anyone I give out the binary to. If I hard code it in, the binary is fine but anyone can look at the source and get it.

My current line of thinking is to create a basic "template class" say "SecretTemplate" or something and also have a "Secret" class. The secret class is in the gitignore and I can put the key in. The "SecretTemplate" is an exact duplicate with instructions to rename it to "Secret" and fill in the details for compiling.

The application will call the static Secret.Key or something when using the API. This seems like a rather hackish way to go about it but would allow me to work on it freely, compile it with ease for binary releases and be relatively simple for others to compile and use (assuming they get their own key/consumer secret).

Thoughts?

# ? Oct 4, 2011 14:09

epswing: Nov 4, 2003; Soiled Meat

I use something like that template method you mentioned.

Say my config file is named config.xml. I tell version control to ignore that file (because it's going to be different for my environment versus another developer's versus the production environment, etc) and I create (and version) a file config.xml.tmpl. It contains a line like:

pre:

SECREY_KEY=~~SECRET_KEY~~

When someone checks out the project, they copy config.xml.tmpl to config.xml and edit in their key.

At that point I usually write a script to inject/replace (via sed, or ant's replace task, etc) all the ~~BLAH~~ parts of config.xml, so I can clone, rename the config file, inject appropriate values, and deploy the project in one click.

Not sure why you'd need a special class in your code...

epswing fucked around with this message at 14:50 on Oct 4, 2011

# ? Oct 4, 2011 14:40

wwb: Aug 17, 2004

+1, this is essentially what I do for disqusssharp.

# ? Oct 4, 2011 14:48

Xik: Mar 10, 2011; Dinosaur Gum

When you distribute a binary your secret key will be viewable to the end user if it is stored in a config file, unless I'm missing something completely obvious (very likely).

What stops someone from just opening up the XML file in a text editor and looking at your secret key?

# ? Oct 4, 2011 14:59

wwb: Aug 17, 2004

I finally got sick of dealing with SVN, so I'm forcing HG down the designers throats today. Wish me luck.

# ? Oct 4, 2011 15:19

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

I had two graphic designers at my side job using Git. It went remarkably well, actually. I was so proud when one of the designers asked me why there were divergent history and merges when it was just me (at the time) working on the website. (Hot fixes on the live server while working on larger features on a local machine.)

# ? Oct 4, 2011 17:05

epswing: Nov 4, 2003; Soiled Meat

Xik posted:

When you distribute a binary your secret key will be viewable to the end user if it is stored in a config file, unless I'm missing something completely obvious (very likely).

What stops someone from just opening up the XML file in a text editor and looking at your secret key?

Oh, I see, this isn't a web-app (or other centralized program). Sorry, I didn't read closely enough.

The api key is for some service your program uses? Why can't the end users get their own api key? Or if that's not feasible, you could host your own proxy service which always uses your api key to the actual service, and you provide each client with their own api key to your proxy service.

Not saying these are great ideas, I don't know what your program does, nor what the api is even for.

vvv E: Yeah, Xik, you can't "hide" your key in a binary, I forgot to mention.

epswing fucked around with this message at 19:02 on Oct 4, 2011

# ? Oct 4, 2011 18:32

Smugdog Millionaire: Sep 14, 2002; 8) Blame Icefrog

Xik posted:

What stops someone from just opening up the XML file in a text editor and looking at your secret key?

Nothing, which coincidentally is exactly what is stopping them from opening your .exe in ILSpy and looking at the value of YourApplication.Secret.ApiKey.

# ? Oct 4, 2011 18:52

wellwhoopdedooo: Nov 23, 2007; Pound Trooper!

Xik posted:

When you distribute a binary your secret key will be viewable to the end user if it is stored in a config file, unless I'm missing something completely obvious (very likely).

What stops someone from just opening up the XML file in a text editor and looking at your secret key?

What stops someone from opening your compiled app in .NET Reflector and looking at the secret key?

Go ahead, download it, open the EXE, see how easy it is to find.

# ? Oct 4, 2011 23:29

wwb: Aug 17, 2004

Lysidas posted:

I had two graphic designers at my side job using Git. It went remarkably well, actually. I was so proud when one of the designers asked me why there were divergent history and merges when it was just me (at the time) working on the website. (Hot fixes on the live server while working on larger features on a local machine.)

Sweet, there is hope. Dilemma I'm facing is I can either teach them to merge or just have them work in the main integration branch. Any advices?

# ? Oct 5, 2011 00:41

Adbot: ADBOT LOVES YOU

# ? May 11, 2024 22:09

Xik: Mar 10, 2011; Dinosaur Gum

You guys are right, there is nothing stopping someone from using another piece of software to view the key within the binary. If someone really wants it they will get it I suppose.

It's really not all that important in this particular case, but I thought that this would be such a common problem these days that the problem would have been "solved" somehow. Especially with the market being flooded with useless applications which use things like the twitter, facebook, flikr API etc....

# ? Oct 5, 2011 00:51

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

«‹›100 »