You can call me whatever you like as long as I know its to me.

I'm not saying it's going to be trivial (although you might be surprised how often it ends up that way), but my experience with git is that it reduces the crap you have to deal with to the actual true conflicts. Often that's not too bad.

My experience with svn (and cvs - although I guess that's even worse than svn) was that I got a whole crapload of messed up stuff. And if you didn't tag or merge exactly properly - you were in for a whole complete world of hurt.

Edit:

And, of course, there's the argument that with git merging is so easy that you just do it all the time.... . I'm actually not a huge git advocate in the sense that I think its the absolute best. I'm sure there are other good tools out there, but my life got much easier when we switched from SVN to Git. It was a much bigger change than we went from CVS to SVN.

I like the "always use branches and merge" work flow a lot. Whenever I work on a repo I do something like:

- create a new temp branch (name will be based on what I'm working on) + check it out.
- start developing / committing to the branch.
- merge it to the primary branch (master, development, etc.) when I'm done.
- delete the temp branch.

It's neat because if let's say some huge issue arises and I need to drop what I'm doing and work on something else I can just stash the branch away and switch to what needs to be worked on, finish that, then come back to the stashed branch and commit/merge it when I finally finish it.

shabby,

i'll admit that i still have never really used git, but i understand the design and the philosophy and i have experience with several other version control systems (lots with svn and cvs; moderate amounts with perforce, rcs, and (shudder) vss).

ime, svn is fine at handling merges as long as your workflow is sound. if you have colleagues who do weird things and don't understand what they're doing, things are less good, but i also think you're boned no matter which tool you're using. some of the sticky details are, shall we say, subtle (svn:mergeinfo anyone?) but you *usually* don't have to care about them.

git seems cool and well-suited for certain kinds of development, especially open source-style development with a widely-distributed, loosely-organized team. however i think that its reputation for being good at handling merges has as much to do with its user base -- smart, motivated developers who understand their tools -- as it does with anything about the design or implementation of git itself. i mean, all VCSes are just layers on top of diff+patch, right? how much better can one tool be?

shabby, what is your development group like? how big? what kind of development are you doing? i ask because if you have experience with a non-trivially-sized team transitioning from svn to git, i'd love to hear about it. a couple of the devs i work with are git lovers/svn haters and would love to switch. but i look at other folks in the department who barely understand svn by using gui tools and wonder how these people will prevent their brains from melting if presented with the chaos of git.

this is a popular workflow and works well for certain people and certain situations. the danger is that it leads to developers working on their own projects in isolation and potentially creating a painful integration cycle at the end (like the one irishthug described).

for example, imagine you're working on your final project for a class with 3 other devs. you could divide the work into 4 buckets, have each person work on one bucket, and then meet at the end to put your code together and turn it in. if you divided the work well and if everyone's code is correct, this would probably work fine.

if you have ever worked on a significant software project that worked like this, let me know!

I never used svn (went straight to git) but I think the main benefit of it is its core functionality. In svn, isn't it a 1 to many relationship between the repo and the devs? Every single person posts to 1 repo?

With git, there's nothing stopping you from being the primary owner of another person's open sourced repo. You can just fork it, and now you have 100% full control over the project in your own isolated environment.

If you're doing some work on the project and the original author thinks what you did was great, you can make a pull request which he could accept and now your code is merged from your fork into the main original repo.

That's the real power of it IMO. Now you have a many to many relationship between the project and the developers.

You don't need to be a wizard to use it either. http://progit.org/book , read that in an afternoon and you're good to go. If you can't understand at least how to use it after reading that then you shouldn't be a developer in the first place.

http://progit.org/book/ch5-1.html is a pretty good run down on a few popular work flows.

You shouldn't be in isolation for very long. You can constantly fetch/merge code (automatically with tools).

I only have experience working with 2 people. I'm not sure how well it would work with 500 people.

Yes, git surely has value in a decentralized environment, with multiple canonical tree. That's what it was designed for, because that's how Linux works. 50 million trees out there working autonomously, all pulling different patches and forked from different versions.

that many-to-many relationship you describe is actually counter-productive in some situations, such as a team developers working at a company producing software. there is no forking. i don't *want* you to be able to do whatever you want. the extra power and complexity doesn't help, so it just makes things more confusing for the user.

i think you also overestimate how willing the average user is to learn a tool as complex as a VCS.

yes, this is definitely a requirement for making this workflow successful.

but imagine if everyone is working like you, only committing on their own branches. now you have to pull changes from each developer and integrate them locally. if you have more than one or two developers, this gets out of hand quickly and you would be better off with a single trunk so that the work of integration is distributed, both over devs and over time.

The local branches are just that, local. They are never pushed as a specific independent branch to your own forked remote repo, or the "blessed" repo.

You might have 2 branches in a git project:
master, development

So now, let's say I just cloned the entire repo and it's sitting on my HD locally. I decide I want to fix a bug, let's call it #333 (it was listed in some make believe bug tracker).

I would just make a branch called bugfix_333 or whatever, and start working. This could be named anything really, it doesn't matter.

When I'm done fixing the bug I merge it back to the local repo's development branch and delete the bugfix_333 branch then push it to the remote repo which could be my own fork of the "blessed" repo, but doesn't have to be... depends on what type of work flow you decide on.

All of this takes about 3 seconds of typing once you're familiar with working with git.

Edit:
I honestly spend more time thinking of descriptive commit messages (which can be done off line btw if you happen to not have an internet connection) than fumbling around with the git commands and I'd still consider myself to be a newbie with git.

Trying to get a new website deployed tonight, ugh lol! Been too long so need to get it done this weekend, bottle of wine and a long evening ahead of me )

I don't agree with this. I mean the extreme example is CVS. If you tried merging a branch twice or if you didn't tag your branch just properly merging became a nightmare. Git isn't just distributed, it's also much smarter in how it determines what a change even is.

Here's a rough timeline of my relevant versioning control system history:

From 2006-2008 I used CVS in a group of 10-40 developers (grew over time). Most projects were semi-independent and had active development by 3-8 people teams. This was a nightmare. This was a very strong team and we constantly had merge problems and branching arguments.

In 2008 we switched to SVN for a really big project that had about 30-40 developers. Everyone agreed it was better, but it didn't make a huge difference.

Over 2009 and 2010 we switched to Git (a few projects at a time) until all 60-70 devs were using. Nobody was unhappy with the switch (which is really pretty damn impressive). There was a little bit of pain in terms of learning how to use it (just switching how you think about versioning) but it didn't last very long.

I'm now using Git at my new company where there are only 5 of us. We follow a super simple branching practice (http://nvie.com/posts/a-successful-git-branching-model/) and it works great.

Honestly, it's not that hard. If they're dumb and scared just keep them to the simple commands of checkout, push, pull. Once they're comfortable with that, you should be good to go. There's also some good Git GUIs appearing if that's a major hangup.

One thing you can do is use git on top of a svn repository. I don't know all of the details, but a couple of guys at work did that to show people how easy it was to learn/use git (and because they liked it better than svn).

Most places that use git still have an idea of a 'central' repo. It's not really special (I don't think), but it's the place changes get pushed to and get pulled from. You don't have to pull from each developer individually (although you can if you'd really like).

Edit: So, for example, we have a github repo where we pull from and push to. I never connect to other people's repos. If I need changes from a dev (that shouldn't be in a common or shared branch) the dev will cut a separate feature branch and push that to the github repo for me to pull down.

jjshabado,
Yes svn merging does suck. We are in the process of seeing if we can migrate to git and have it do all the things we need it to. It is used on newer programs in the department, so there is hope. I'm not directly involved in the process, but the one thing I heard someone complain about is access control. We have sections of the tree that not everyone can have access to (not even read access). The funny things is that the main reason for considering the change is because there are times were a large number of people are off site with bad connections back to the main server, not because merging is a bitch.

tyler_cracker,
It does sound crazy, and to an extent it is. However, there is are some explanations. The reason for the branch was that we were being stalled by acquiring a license to a library we needed. So I could not check in the code that used the libraries to trunk because without the libraries, the nightly builds would crash. The other thing is that the program I'm writing is a support tool for the main line project. The main line is regularly tested and simulations are run, but the support tools are not. It is also a DARPA project so you have to pitch big to get funding. If the thing you pitch seems like it will be straight forward and guaranteed to work, they are not interested. It is a very different world than a commercial product. Not saying it is perfect, but it is the way it is.

I openly acknowledge that I'm not great at Linux. I'm not really good at computers, I'm just a good programmer. People have said the right way to do it, but it doesn't look like anyone actually explained why the other one doesn't do what you expect it to.

Continues git talk:
With my next personal project, I'm going to use git. Even though it will just be me, I'm still going to try and stick with a branching model like the one jj linked to. It wasn't until I watched this video and actually saw git in action that the pieces started to piece together and I understood how it can work. Big merges are still going to be hard, but if you focus on branch/small change/merge, you won't have to do lots of big merges.

It seems like a hybrid model would work best. It is still technically distributed, but there is still one server that is treated as the golden repo. The nightly builds and tests work from that to ensure the final quality.

I have no idea what */* would be expected to do. I'm also no expert, but I don't think that's a valid expression for any linux command. The closest I can guess is it's kinda like *.* in dos, but with a slash so it's for folders ldo

my first thought was "don't you use -r for recurse through folders?" turns out it's a capital R for this command, maybe it is for the one you must remember never to do without extreme caution "rm -rf" lol

http://www.faqs.org/docs/abs/HTML/globbingref.html

Thanks. thinking about it more, it is a valid expression for match any file exactly one subfolder deep?

Exactly.

Yes, this is one thing that kind of sucks about Git. You can't checkout a portion of the repo or give access to a portion.

My understanding is that the 'correct' solution is to break the repo up into separate git repos - which I'm not sure is viable for some projects.

With Git you could have kept merging the main build into your personal feature branch. Then when you turn around and merge your feature branch back into main it's a pretty trivial merge.

I don't know if SVN can easily handle a workflow like that.

yes, i work with several devs who do this all the time.

I'm so glad this forum exists

code formatting q

i find myself using a lot of if's that end up cascading:

should i be doing it like this?

but the expressions are usually long, so

If your expressions are short enough I like option 2. If they're longer I like option 3. I dislike option 1 immensely.

On a side note: although you provided a very shallow example as far as nesting is concerned this is generally known as a code smell, namely the Arrow Anti Pattern.