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 »

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

not a dinosaur posted:

I was hoping that I could store all three projects as independent branches in my repository, and then do some kind of "merge into directory" thing, where I merge a local branch into a subdirectory of another. Is this possible? What's the best way for me to handle this?

You could just add the two subdirectories to .gitignore.

If you need this directory structure, and you'll be making changes to them as a group, what makes you say they are separate projects?

# ? Nov 8, 2011 04:29

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 01:02

Comrade Gritty: Sep 19, 2011; This Machine Kills Fascists

Dromio posted:

I'm think I'm "doing it wrong" with git and trying to force it to follow my desired workflow.

I have a branch called "Production" that contains the code that's currently on Production.
I have a branch called "Development" that contains all the code that's been in development and the developers feel like might be ready for release, but is untested.
I have multiple feature branches like "feature/addTotalCountToReport" where a developer implemented a specific feature.

When a developer starts a task, they make a branch off "Development" and start their work. When they're done with the task, they push their feature branch to origin and merge it back into Development so it gets automatically built on our shared dev server for testing.

Then our QA guy comes to me and says "I want to deploy feature/addTotalCountToReport, but not feature/bigGiantChange because it still needs work". Originally I thought it was as easy as merging feature/addTotalCountToReport into my Production branch and building. But because that was branched from Devlopment originally, when I merge it'll bring in code from previous development branches that might not be wanted.

So how do I fix this? Should feature branches be built off Production, not Development? I think this might confuse the developers because they won't see the bugfix they did yesterday.

Or do I cherry-pick all the commits from the feature branch into Production? That seems kind of nasty, but seems to work.

What you are doing is basically git flow (minus being able to deploy a feature to production without first making a release from dev.)

We solved it just by saying "never merge into the dev branch until your feature is ready". The idea being that at any time you can take your dev branch, make release/next-version, do any cleanup, or pre release bookkeeping, and then release that release. Also by telling people "no, you can't have X feature until the next release".

There's also the possibility of taking feature/X and rebasing it from dev to ontop of production, but that may or may not be an exercise in pain depending on how much further ahead dev is.

# ? Nov 8, 2011 14:51

Golbez: Oct 9, 2002; 1 2 3!
If you want to take a shot at me get in line, line
1 2 3!
Baby, I've had all my shots and I'm fine

I'm liking git but it's starting to drive me insane. Please help.

Before, our process would be: I would use Winmerge to periodically merge my new code into the test or live copy, or to push and pull changes between my development environment and the other coder's development environment. This way, my code was always the center of it. I would push to test, test would push to live, and I would determine everything. I would make sure his code was up to date.

But now we got git, because we had no version control at all before.

So I have a master repository, which is the current live version of the website. I have a test repository which is where we throw things that need to be tested by others (a hook copies this to our test domain). And then we have our development repositories, though we may be abandoning those for simply using branches for development. That's how I've gone, at least.

So let's say he's working on feature A, branched off master. I then have to work on a hotfix. I make it, I check out his dev environment and try to merge into it... and it wants to delete all the files he's added in his branch.

How can I easily pick and choose what git will change in a merge? What if I just want to merge in one file? While master is safe, our branches are growing more and more out of sync with each other and it's starting to drive me crazy. When I see "Removed ..." a bunch of times in a git merge, I get terrified and reset. The last thing I want to do is delete his code.

And am I treating this all the wrong way? I know a large part of this is that we shoehorned our existing codebase and development practices into git, and I'm not sure how to fix it.

# ? Nov 8, 2011 16:17

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

You need to understand that the different checkouts you have on your various systems are not different repositories, but clones of the same repository in different states. Whenever you do something to any of the checkouts of this repository, it will try to eventually end up in a state where everything is synched. If you merge the master branch of one repo with the master branch of another it tries to make the more current state authorative.

Now, what you want to do instead is to just use different branches. One where you develop in, one where testing stuff goes in and then the dev branches for various people, who each have their own feature branches. (Note you can create branches like "dev/people/golbez".) And even better: If you set up gitolite you can configure access restrictions of who can push to what branch and whether they can force push or not.

To answer your question though:

Golbez posted:

How can I easily pick and choose what git will change in a merge?

do the merge with --no-commit. Then it just builds a commit in the staging area, which you can interrogate and fiddle with. Git-Gui is awesome for that, since you can throw out or add in individual lines. (You might need to click on the amend radio button.) When you then commit, the merge will be created.

# ? Nov 8, 2011 16:49

Johnny Cache Hit: Oct 17, 2011

Golbez posted:

So let's say he's working on feature A, branched off master. I then have to work on a hotfix. I make it, I check out his dev environment and try to merge into it... and it wants to delete all the files he's added in his branch.

It sounds like you are trying to merge master onto his branch. You probably don't want to do that. Instead:
1. Check out master, make the fix, commit, push, etc.
2. On his feature branch, git fetch master, and then rebase his changes onto master.

This should fast forward his branch to live so that his feature branch has the latest live work. In effect, his branch goes from:

code:

X - Y - Z - A
        \ - feature commit - some other commit

code:

X - Y - Z - A
             \ - feature commit - some other commit

# ? Nov 8, 2011 16:53

Golbez: Oct 9, 2002; 1 2 3!
If you want to take a shot at me get in line, line
1 2 3!
Baby, I've had all my shots and I'm fine

Mithaldu posted:

Now, what you want to do instead is to just use different branches. One where you develop in, one where testing stuff goes in and then the dev branches for various people, who each have their own feature branches. (Note you can create branches like "dev/people/golbez".) And even better: If you set up gitolite you can configure access restrictions of who can push to what branch and whether they can force push or not.

Already have gitolite set up, thanks to a recommendation from earlier in this thread.

I haven't been using a dev branch because I can't get a local dev environment working, so I've been doing all my testing on the remote site, and I'd rather not have to commit every single time I want to test new code. I just check out whatever feature branch I'm working on at that moment. Then when it's ready for testing, I merge it into test, then when it's ready for live, I merge it into live.

quote:

To answer your question though:
do the merge with --no-commit. Then it just builds a commit in the staging area, which you can interrogate and fiddle with. Git-Gui is awesome for that, since you can throw out or add in individual lines. (You might need to click on the amend radio button.) When you then commit, the merge will be created.

I completely forgot about git gui. So, I can do that, and git gui will allow me to say, "Hey, I actually don't want you to delete this file"?

My hope is after we get these projects pushed live, the ones that existed before moving to git, that the whole process will become much easier.

Part of the problem is that we're an internal website, so we don't have releases, etc. We just push new features as they happen. So I'm not sure it makes sense to maintain a development branch that will eventually be merged into master.

My eventual hope is that: We have master. We have test. We have feature branches that are branched off master. We merge them into test as needed for testing, then merge the branch into master when testing is complete. Then, I suppose, replace test with master and start over, pushing test branches back into it. ... Which I'm not sure makes sense. Part of the issue is that we can't just merge test into master because not everything on test is ready for master, but I like the idea of merging a feature branch into master because it's supposedly self-contained.

I find myself thinking I'm rambling incoherently whenever I talk about git. :sigh:

Sorry.

quote:

It sounds like you are trying to merge master onto his branch.

My hotfix was a branch off master, does that still count as trying to merge master on his branch since it's a more recent branch? I'm trying to never edit master directly.

quote:

This should fast forward his branch to live so that his feature branch has the latest live work.

Can you please explain fast forwarding for me? I've been working off the structure described here which suggests always using --no-ff when merging.

# ? Nov 8, 2011 17:28

Johnny Cache Hit: Oct 17, 2011

Golbez posted:

Can you please explain fast forwarding for me? I've been working off the structure described here which suggests always using --no-ff when merging.

I'm no git expert, but wow -- that workflow looks intense.

All I can say is that I like simple rebase centered workflows because they are simple and just work.

For that workflow you'll want someone who really knows git to chime in. Sorry :smith:

# ? Nov 8, 2011 19:22

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

Ok, i see your issue. Your talk about repositories confused me.

Golbez posted:

We have master. We have test. We have feature branches that are branched off master.

This is not what you want to do.

Instead you want to have master, and feature branches, and a test system that you can configure to check out an arbitrary branch and test it. That way you will only merge when you combine two features or want to put a feature life. For extra points: Start using tags and have your test system (if it runs automated tests) check out all tags starting with test_ automatically, test them and publish results on an internal website.

As for git-gui: Yes, exactly that.

Golbez posted:

Can you please explain fast forwarding for me?

It's the same thing as what happens when you update in SVN.

Have you watched this video yet? http://blip.tv/open-source-developers-conference/git-for-ages-4-and-up-4460524

# ? Nov 8, 2011 19:57

Golbez: Oct 9, 2002; 1 2 3!
If you want to take a shot at me get in line, line
1 2 3!
Baby, I've had all my shots and I'm fine

Kim Jong III posted:

I'm no git expert, but wow -- that workflow looks intense.

All I can say is that I like simple rebase centered workflows because they are simple and just work.

For that workflow you'll want someone who really knows git to chime in. Sorry

Well we haven't been following it exactly, just using it as a basis. We don't have release branches.

quote:

It's the same thing as what happens when you update in SVN.

Git is my first version control system, so this means nothing to me. :downs:

quote:

Instead you want to have master, and feature branches, and a test system that you can configure to check out an arbitrary branch and test it. That way you will only merge when you combine two features or want to put a feature life. For extra points: Start using tags and have your test system (if it runs automated tests) check out all tags starting with test_ automatically, test them and publish results on an internal website.

But what if we need to test two branches at once? And by test, I mean "put up so people in the office confirm it works as desired", not unit testing.

# ? Nov 8, 2011 20:24

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

Golbez posted:

Git is my first version control system, so this means nothing to me.

In simple terms then: When you're pulling commits from a remote repository, git checks if there are any conflicts between your local new commits and the ones it's pulling in from the remote. If there are none, it will temporarily detach your local commits, stack the remote ones on, and then reattach your local commits on top of that. All without creating a specific merge commit.

Golbez posted:

But what if we need to test two branches at once? And by test, I mean "put up so people in the office confirm it works as desired", not unit testing.

Then you create a new branch into which you merge the two features and when you're done you delete it again, by doing:

git branch -D two_feature_test
git push remote_name :two_feature_test

The point is: In your situation what you're testing changes around too much, so having a single test branch is not viable while retaining a sane workflow.

Also: Watch the video. Now.

# ? Nov 8, 2011 20:36

Golbez: Oct 9, 2002; 1 2 3!
If you want to take a shot at me get in line, line
1 2 3!
Baby, I've had all my shots and I'm fine

OK, I watched, and understand much better the whole notion of how git moves commits and tags around.

A new wrench has been thrown into the works, though. We've been told we have to push our development code daily to a host on the site, we can't just push our feature branches to test when we want.

Is it possible to set up a branch so that it can be automerged into a particular other branch? Like, is it possible to have the following:
* master
* test
* dev
* dev/reports
* dev/fancy
* test/tickets

And a hook that, whenever we commit or push something to dev/reports or dev/fancy, it also gets merged into dev? (And how would I make these names, anyway?) And if we commit something to test it also gets merged into test (and, perhaps also, dev)? And am I singlehandedly unraveling all advantages git offers by wanting to do this?

# ? Nov 8, 2011 22:31

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

Golbez posted:

OK, I watched, and understand much better the whole notion of how git moves commits and tags around.

Awesome.

Golbez posted:

A new wrench has been thrown into the works, though. We've been told we have to push our development code daily to a host on the site, we can't just push our feature branches to test when we want.

This is pants-on-head stupid. Not because of git or anything, but because of the frank reality of development. A feature that's in a branch is not yet ready and has no business being on any system. And if it's ready it has to be in test.

Golbez posted:

Is it possible to set up a branch so that it can be automerged

No, since conflicts could happen.

I have an idea of what you could do to make everyone happy, but before that i'll need a detailed list of all your deployment hosts as well as their purposes.

# ? Nov 9, 2011 11:21

Golbez: Oct 9, 2002; 1 2 3!
If you want to take a shot at me get in line, line
1 2 3!
Baby, I've had all my shots and I'm fine

Edit: Turns out the main reason he wanted everything on the server was for backup purposes. That, I can live with - it should be simple enough to run a script that backs up our local branches to the network, right?

Golbez fucked around with this message at 16:57 on Nov 9, 2011

# ? Nov 9, 2011 16:11

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

Golbez posted:

Edit: Turns out the main reason he wanted everything on the server was for backup purposes. That, I can live with - it should be simple enough to run a script that backs up our local branches to the network, right?

Oh good, then i can stop trying to figure out a way to resolve that ball of yarn. I'll assume by "local branches" you mean the branches stored on developer workstations.

Just start making feature branches like this:

code:

git checkout -b people/golbez/ajax_spinners

Additionally configure your gitolite so that each person can delete/force-push/etc. in people/<theirname>/*. That way everyone can fiddle around with poo poo how they like, but still push at the end of the day.

It's actually fairly neat, because that way everyone can easily see what everyone else is working on.

# ? Nov 9, 2011 17:04

Golbez: Oct 9, 2002; 1 2 3!
If you want to take a shot at me get in line, line
1 2 3!
Baby, I've had all my shots and I'm fine

Mithaldu posted:

Oh good, then i can stop trying to figure out a way to resolve that ball of yarn. I'll assume by "local branches" you mean the branches stored on developer workstations.

Correct. I can't see his branches, I don't think he can see mine.

quote:

Just start making feature branches like this:
code:
git checkout -b people/golbez/ajax_spinners
Additionally configure your gitolite so that each person can delete/force-push/etc. in people/<theirname>/*. That way everyone can fiddle around with poo poo how they like, but still push at the end of the day.

It's actually fairly neat, because that way everyone can easily see what everyone else is working on.

What does that? All you said was do people/golbez/whatever, but does that alone push it to the central repo or do I need more settings/hooks?

# ? Nov 9, 2011 17:13

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

Golbez posted:

Correct. I can't see his branches, I don't think he can see mine.

What does that? All you said was do people/golbez/whatever, but does that alone push it to the central repo or do I need more settings/hooks?

Ah, sorry if that was unclear. That creates a branch of that name in your repository on your local harddrive. When you push it to your gitolite, everyone else will be able to see it when they do a git fetch or git pull.

# ? Nov 9, 2011 17:58

WrecklessSandwich: Jul 29, 2005

Fairly new to git (more experience with SVN) and got myself in a bit of a mess that I'm not sure how to fix. I'm working on the hardware design for a development board and associated software libraries for the two microcontrollers on the board. I set up a git repository when I first started working on the hardware side that I want to use for the whole project.

The repository: https://github.com/jbaker0428/Unified-Robotics-Development-Board

I was hoping the PCB project folder would be created as a subfolder on the repository instead of the files in the (local) project folder being placed in the root of the repo. I somehow didn't notice until just now when I went to start working on the software. It was around this point that I realized that I have no idea how to do anything advanced in git.

Desired end result:

PCB design files moved to a subfolder within the git repository, preferably without losing their existing revision history.
PCB design files in the same location on my local hard drive as they are now.
Source code for the two microcontroller libraries in their own subfolders within the git repository.
The two microcontroller library projects are also in different workspace folders on my local drive (they're different hardware that uses different IDEs).

Some thoughts/notes/assumptions:

Using subfolders makes more sense than feature branches here (at least in my mind) because the 3 projects are elements of the same real-world end product, but from a design perspective they're very distinct elements designed in different languages with different software. It's possible that branches make my problem a lot easier with git but I honestly don't know.
I normally use the Git GUI program in Windows, but I'm comfortable with the command line if need be.

I feel like there has to be a fairly simple solution to a lot of this, but I'm missing something obvious here. Is there an easy fix here, or should I resign myself to using different repositories?

WrecklessSandwich fucked around with this message at 08:02 on Nov 10, 2011

# ? Nov 10, 2011 07:58

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

git mv is the command to move and/or rename files. But that will move the files both in the repository which is on your computer, and the repository which is hosted by github, because those things are the same.

WrecklessSandwich posted:

Source code for the two microcontroller libraries in their own subfolders within the git repository.

The two microcontroller library projects are also in different workspace folders on my local drive (they're different hardware that uses different IDEs).

You can do this with submodules: each project is their own repository, and the central project mirrors them in some way? I don't know exactly how it works because submodules aren't so great. Good luck!

Doc Hawkins fucked around with this message at 08:44 on Nov 10, 2011

# ? Nov 10, 2011 08:41

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

I'm not entirely sure i'm understanding you right, because your description is anything but clear, however i get the feeling you just want to use ntfslink to link your pcb directories into your repo.

# ? Nov 10, 2011 13:54

Dromio: Oct 16, 2002; Sleeper

Not REALLY a git question, but it's a problem I'm sure many people have to deal with. How are you handling "transient" code for feature branches in git?

I need to write a new feature. That feature includes the need for an "ALTER TABLE" script on our database to add a new column.

The only thing I can think of is to create a "/Migration/SomeArbitraryName" folder inside the repository on that branch. But then when you merge back to master you end up with a whole bunch of subfolders under the /Migration folder. This seems "nasty" to me. And what would the name of that subfolder be? I could use a bug-tracking ticket number, but sometimes I want to develop without having to deal with a bug tracking system.

Or maybe just a single "Migration.sql" file. When I merge multiple branches in, it'd build up a big script to do all the changes just for those branches. Sounds neat, but maybe I'm missing something important with that.
EDIT: But then I'd end up needing some way to clear it out after pushing it to production. Seemed smart, but that's a bit of a mess.

As of right now I don't have an automated build/deploy for SQL changes, but I'd like to be able to do so eventually when I push these changes to master. How are you handling this sort of thing?

Dromio fucked around with this message at 17:33 on Nov 10, 2011

# ? Nov 10, 2011 17:28

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

Dromio posted:

Or maybe just a single "Migration.sql" file. When I merge multiple branches in, it'd build up a big script to do all the changes just for those branches. Sounds neat, but maybe I'm missing something important with that.
EDIT: But then I'd end up needing some way to clear it out after pushing it to production. Seemed smart, but that's a bit of a mess.

Why would you need to clear it out? You want to have a record of these changes in source control, and don't you also you want to be able to actually do them (and god forbid, undo them) in production?

quote:

As of right now I don't have an automated build/deploy for SQL changes, but I'd like to be able to do so eventually when I push these changes to master. How are you handling this sort of thing?

A migrations folder filled with files that describe changes to the database, and how to reverse them, with names that start with a timestamp and end with something descriptive ("201112250830_addPresentsRowToTreesTable"), along with scripts to apply and un-apply one, some or all of them in series.

I do it that way because it's just how Rails does things by default, but it seems like a good idea! :shobon:

# ? Nov 10, 2011 18:08

WrecklessSandwich: Jul 29, 2005

Mithaldu posted:

I'm not entirely sure i'm understanding you right, because your description is anything but clear, however i get the feeling you just want to use ntfslink to link your pcb directories into your repo.

Interesting workaround, I think with that and git mv I should be able to make it work, thanks.

WrecklessSandwich fucked around with this message at 22:03 on Nov 10, 2011

# ? Nov 10, 2011 21:58

Dromio: Oct 16, 2002; Sleeper

I've been deleting branches from our remote git repository using git push origin :feature/DoThisThing and I thought it was working. But now I go to my OSX machine and do a git fetch; git branch -r and the branch still appears there! How can this be? If I try to delete it again from the OSX machine it tells me that it's an "unqualified destination".

My list of remote branches on this machine is getting really long! Any ideas how to clean this up?

# ? Nov 16, 2011 15:39

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

Dromio posted:

I've been deleting branches from our remote git repository using git push origin :feature/DoThisThing and I thought it was working. But now I go to my OSX machine and do a git fetch; git branch -r and the branch still appears there! How can this be? If I try to delete it again from the OSX machine it tells me that it's an "unqualified destination".

My list of remote branches on this machine is getting really long! Any ideas how to clean this up?

Maybe those branches had been fetched to your OSX machine earlier? I do not think deleting branches on a remote will also delete them on a local repository when fetched. Try deleting them on your OSX and then fetch and see what happens.

# ? Nov 16, 2011 15:45

Dromio: Oct 16, 2002; Sleeper

But how?

pre:

$ git branch -r
...
origin/feature/thisIsDone
...

$ git push origin :feature/thisIsDone

error: unable to push to unqualified destination: feature/thisIsDone
The destination refspec neither matches an existing ref on the remote nor
begins with refs/, and we are unable to guess a prefix based on the source ref.
error: failed to push some refs to 'git@ourserver:ourrepo'

$ git branch -D feature/thisIsDone
error: branch 'feature/thisIsDone' not found.

$ git branch -D origin/feature/thisIsDone
error: branch 'origin/feature/thisIsDone' not found.

We're using gitolite for the origin repository, if that makes any difference. It's weird that they're showing up here on the OSX machine but not on my Windows/msysgit machine.

# ? Nov 16, 2011 15:59

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

git remote prune origin will delete your local copies of remote branches that no longer exist. This process is not automatic.

# ? Nov 16, 2011 16:05

Dromio: Oct 16, 2002; Sleeper

Lysidas posted:

git remote prune origin will delete your local copies of remote branches that no longer exist. This process is not automatic.

That did it! Thank you very much.

I love using git, but every time I have to tell my team about one more esoteric thing like this I see their faces grow a little bit darker. The benefits are enormous, but there really are a lot of :wtf:

moments.

# ? Nov 16, 2011 16:08

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

Yeah, it helps to remember (and may also help to tell your team this) that one of the high-level design decisions in Git is to be completely paranoid about preserving information in your local repository. Most of the time you have to explicitly tell Git when you want to remove some information, with the notable exception of reflog entries expiring after some large number of days so that unreachable objects can be pruned by git gc --auto.

Remote ref disappeared? Trouble might be afoot. :ninja:

# ? Nov 16, 2011 16:26

Reo: Apr 11, 2003; That'll do, Carlos.
That'll do.

Myself and 1 other developer in another state are working on a project. We need the simplest (free) version control system we can get for Windows, where we can check out/share/merge our changes together over the internet, but have it remain private to just us.

I've tried to install Git with SmartGit and Bitbucket, and it just seems over my head, we don't know what commits, branches, etc. are. We just want to prevent overwriting each other's changes on an ftp server.

Any suggestions? Thanks.

# ? Nov 21, 2011 20:37

Johnny Cache Hit: Oct 17, 2011

Reo posted:

Myself and 1 other developer in another state are working on a project. We need the simplest (free) version control system we can get for Windows, where we can check out/share/merge our changes together over the internet, but have it remain private to just us.

I've tried to install Git with SmartGit and Bitbucket, and it just seems over my head, we don't know what commits, branches, etc. are. We just want to prevent overwriting each other's changes on an ftp server.

Any suggestions? Thanks.

You're going to have to invest some time learning a VCS. Not knowing some version control system is like being a programmer and editing your code strictly in Notepad - completely impossible to scale beyond trivial tasks. And unfortunately I don't know of any good VCS that makes your simple case possible...

I'd suggest Mercurial, because it rocks on Windows with TortoiseHG, and you can get free private repos from Bitbucket, which means you don't also have to administrate a server to host your code.

Here are some well-recommended Mercurial tutorials:

http://hginit.com/
http://hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html
http://mercurial.selenic.com/wiki/Tutorial

# ? Nov 21, 2011 20:50

Reo: Apr 11, 2003; That'll do, Carlos.
That'll do.

Well, thanks. The tutorials will definitely help.

# ? Nov 21, 2011 21:20

duck monster: Dec 15, 2004

Reo posted:

Myself and 1 other developer in another state are working on a project. We need the simplest (free) version control system we can get for Windows, where we can check out/share/merge our changes together over the internet, but have it remain private to just us.

I've tried to install Git with SmartGit and Bitbucket, and it just seems over my head, we don't know what commits, branches, etc. are. We just want to prevent overwriting each other's changes on an ftp server.

Any suggestions? Thanks.

Is source safe still a thing. Back in the late 90s we where using it at work and it was really underpowered and really easy to use. God help you when it gets confused however.

Seconding mercurial however, its become my weapon of choice, and its very easy to use. Its a bit of slug compared to git, but not by enough to make it much of a problem.

I'd suggest if your coordinating between two devs, get an instance of redmine or trac (trac is a bit lighter on ram, but its a bit ugly. Agilo makes it very shiny though) and hook it to your repository and use that to sync between you. If you've got a meaty enough server, adding jenkins to run your unit tests is very swish. Heck you can even use it to do continuous integration with iOS apps, if the server is a mac.

duck monster fucked around with this message at 03:43 on Nov 23, 2011

# ? Nov 23, 2011 03:40

Johnny Cache Hit: Oct 17, 2011

duck monster posted:

Is source safe still a thing. Back in the late 90s we where using it at work and it was really underpowered and really easy to use. God help you when it gets confused however.

Run away from it screaming -- it refuses to actually keep your source safe.

There are a ton of nasty bugs that lead to silent corruption/loss of files in your repository. Plus it requires SMB to actually share files, which means in this case a VPN would be needed.

MS finally got the picture and killed it a few years ago. I've heard they thought so poorly of it that it wasn't used inside Microsoft.

e: thanks for mentioning Agilo. I'd never heard of it before but it looks awesome.

# ? Nov 23, 2011 14:27

wwb: Aug 17, 2004

duck monster posted:

Is source safe still a thing. Back in the late 90s we where using it at work and it was really underpowered and really easy to use. God help you when it gets confused however.

Seconding mercurial however, its become my weapon of choice, and its very easy to use. Its a bit of slug compared to git, but not by enough to make it much of a problem.

I'd suggest if your coordinating between two devs, get an instance of redmine or trac (trac is a bit lighter on ram, but its a bit ugly. Agilo makes it very shiny though) and hook it to your repository and use that to sync between you. If you've got a meaty enough server, adding jenkins to run your unit tests is very swish. Heck you can even use it to do continuous integration with iOS apps, if the server is a mac.

Bitbucket has an issue tracker that isn't insanely awesome, but works well enough for a 2 man team and obviously integrates with their scm.

Jenkins is cool but teamcity is cooler.

# ? Nov 23, 2011 14:56

enki42: Jun 11, 2001; #ATMLIVESMATTER

Put this Nazi-lover on ignore immediately!

Another awesome option for bug tracking / continuous integration is Jira + Bamboo. It isn't free, but for less than 10 people it's a $10 one-time fee for each (you might want to bump it up to $30 and get a Greenhopper license as well since it's amazing and makes Jira a billion times better.)

Jira is almost certainly overkill for a 2 man team, but it's still dead simple to use, and it will scale to pretty much any workflow you could possibly want.

Bamboo is optimized towards building Java projects out of the box, but I didn't find it too difficult to get Rails projects building on it.

As an added plus, Atlassian (the company who makes all this stuff) owns Bitbucket, so the integration between Jira / Bamboo and Bitbucket is pretty awesome.

# ? Nov 23, 2011 15:38

Horse Cock Johnson: Feb 11, 2005; Speed has everything to do with it. You see, the speed of the bottom informs the top how much pressure he's supposed to apply. Speed's the name of the game.

Is the Mercurial book linked in the OP still the best/most current on the subject? Has Mercurial even changed enough since 2009 for it to even matter? Or is there a more up to date book I should read?

# ? Nov 28, 2011 18:19

wwb: Aug 17, 2004

Probably, Bryan O Sullivan wrote HG after all.

Only thing I would add is http://hginit.com as a good way to get people going with HG. They just need to ignore the ads for sploskyware.

# ? Nov 28, 2011 19:19

uXs: May 3, 2005; Mark it zero!

Horse Cock Johnson posted:

Is the Mercurial book linked in the OP still the best/most current on the subject? Has Mercurial even changed enough since 2009 for it to even matter? Or is there a more up to date book I should read?

I don't know about anything better, but it's probably a bit old. It puts a bit too much emphasis on cloning, while mercurial itself has moved in the direction of named branches.

# ? Nov 28, 2011 20:37

Johnny Cache Hit: Oct 17, 2011

uXs posted:

I don't know about anything better, but it's probably a bit old. It puts a bit too much emphasis on cloning, while mercurial itself has moved in the direction of named branches.

Are named branches still permanent, heavy beasts that must exist everywhere? That was what drove me away from mercurial and to git.

# ? Nov 29, 2011 14:55

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 01:02

Jethro: Jun 1, 2000; I was raised on the dairy, Bitch!

Named branches are permanent yes, and the branch name is an attribute of a changeset, so they do have to "exist everywhere", but there has never been anything "heavy" about them (as far as I can tell anyway, from my year or so of playing around with hg). So whatever drove you away from hg probably still exists, but it's not that there's anything wrong with them; they just don't work how you thought they would/would like them to.

# ? Nov 29, 2011 17:47

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

«‹›100 »