Git or Mercurial

[sourceninja]

My work is looking to replace SVN. Our number of projects has grown as has the number of active developers. We want a distributed system with a central repository that represents the current stable release of our products only.

Developers fork the stable, do whatever the hell they want, get it to pass all tests and reviews, then push it back to update stable.

Both git and mercurial seem to handle this well. The only downside I see is that git would require us to push over ssh which might be hard for our windows guys to get their heads around. (They are tortiseSVN users afterall).

Does anyone have an experience with these two they want to share? Especially in exposing a network server to host a main repo everyone will branch/fork from. I'm currently leading to Mercurial because it seems to have better http support (with http pushes as well). But git looks great as well and seems to be a lot more customizable to meet each individual developers workflow.

 

[dinkumthinkum]

I've done Git repos with HTTP PUSH using Apache. Takes a little extra setup. There's a document that explains it.

http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt

 

[sourceninja]

Thanks for the info!

Now that makes it even harder....

 

[dinkumthinkum]

Thanks for the info!

Now that makes it even harder....

Also did you check out Git-GUI for Windows? It makes the basic workflow pretty easy. If you do use ssh, it is integrated with putty.

 

[sourceninja]

Hmm, a windows user friend of mine suggested Bazaar. I guess it actually supports out of the box a centralized server approach and/or a distributed approach, has a cross platform gui that looks really nice, and has TortoiseBZR to replace TortoiseSVN.

I guess what I'm going to need to do is setup all 3, and import some of our projects into them and see how they function with our day to day workflow.

 

[Nothinman]

I've had good luck with git and things like git bisect are awesome, but the last time I looked at git on Windows it didn't seem quite ready. I think it kept thinking the local copy was out of sync with what I was using as the central repo, possibly because of timestamp differences between Windows and Linux, I only have a vague recollection though. And who knows, maybe that's been fixed since I last touched it.

 

[Cogman]

AFAIK, Git is the more popular solution. I hadn't even heard of Mercurial before this thread. Though, popularity doesn't mean it is better, I'm just sayin'.

 

[Markbnj]

Also did you check out Git-GUI for Windows? It makes the basic workflow pretty easy. If you do use ssh, it is integrated with putty.

Yeah, I wouldn't worry too much about the SSH-on-Windows fears. Putty makes it pretty seamless.

 

[sourceninja]

Right now I'm working on a pilot of git and bazaar. I dropped Mercurial because there wasn't much difference I could see between it and git and from playing with local repositories I just felt more comfortable with git.

However I've been looking at bazaar all morning and it looks really well designed. It has nice cross-platform gui's and shell integration with windows via tortoise. It is also a lot simpler to use with each branch having it's own working folder (instead of git's method of using a container). However, I have to see how they work with real data.

So I'm building two virtual servers. One for bazaar and one for git. I'm going to try them with direct ssh (sftp for bazaar), setting up web access, etc.

Our current setup uses SVN and we have 1 repository with folders for each project. Inside each project's folder we have your normal trunk, branch, etc.

I have meet the following criteria.
1) Need to have a central server that stores all of our release code.
2) That central server needs to be browsable because a lot of the time management wants to look though or project lists or they want to look at a project but are not sure of the project's location on the server.
3) We need to provide read only and read-write access to the 'central' repository. This is because we use interns. We don't want them to commit code, we want to pull code from them, verify it then push it ourselves.
4) It has to work on linux, windows, and osx
5) Needs good gui tools for windows. Other operating systems it would be nice, but it's not needed as those are our power users who like the command line.

I want to change the work flow so that everyone checks out from the 'central' server. The central server will always have 3 branches for every repository by default. Stable, testing, and in-review. They can then branch as needed on their own machine to do development work. Merges those branches into one of three branches we have defined above and push it back to the server.

In the case of interns, they will checkout from the central server. Do their work branch as needed, etc. When they are ready they will have one of the developers check out their branch from their computer. That developer will verify their code and when it is ready, he will merge it into one of the 3 branches talked about above and push it back to the server.

I know all 3 (git, bazaar, mercurial) can do this. I'm just not sure which one does it best.

 

[dinkumthinkum]

If you have time to review this kind of thing I wouldn't mind reading your results. I have switched myself from darcs to git and have been pretty happy so far. I do a lot of things you describe,
like multiple working branches, and read-only vs read-write access. darcs flexibility spoiled me but I have pretty much been able to duplicate that functionality with git and have the benefit of git being well maintained.

 

[sourceninja]

Well, so far this is what I've discovered.

Performance was measurably different between bazaar and git with git being slightly faster, however in actuality I couldn't tell the difference. In terms of tools, both had good tools on mac and linux, but windows is where bazaar shined. The TortoiseGit and git extensions projects both fail in comparison to TortoiseBzr. And bazaar's explorer is also very nice.

I terms of workflow, I like the way git works. I like how git handles branches and merges. I like how you have to add files to a staging area before committing. Often times I want to commit files in batches to have more detailed comments. Bazaar supports this, but it is an exclusion method and not an inclusion method.

Both worked fine over ssh on windows with and without using key authentication (although git extensions would not work without using key auth). Bazaar has the advantage of being able to work over sftp as well. That is a non starter to us however as this is all internal and key based ssh is probably the best method.

Sadly none of the graphical tools had an easy way to browse all repositories on a server over ssh. Again one of my concerns is with the 70+ projects we have sometimes you don't know the name of the folder or branch you need to checkout. With SVN all of our projects were in one repo, so you could browse it. With git and bazaar each project has it's own repo, so I'm still looking for a easy way to browse them. This may be where things like gitnosis could shine. I'll probably try setting something like that up next week when I get back to work.

Over all I can see our company picking bazaar because of it's strength on the windows tools side. However I haven't tested out mercurial yet, so time will tell.

 

[Cogman]

..Performance was measurably different between bazaar and git with git being slightly faster, however in actuality I couldn't tell the difference...

Wait, What?

 

[sourceninja]

Wait, What?

The difference in speed was measurable, but so minute a human can't tell. Like playing a game at 90fps vs 87fps.

 

[dinkumthinkum]

gitosis might work out for you. I just setup gitweb.cgi with the same Apache settings as the repository and browse it with Mozilla.

 

[JasonCoder]

Out of curiosity, what was the problem that SVN could not solve?

 

[sourceninja]

Mostly two things.

1) Branching. SVN simply sucks at branching compared to git. So rather then make branches, I'm constantly making copies of the code to test new features out, then copying it back when it is ready and thus losing all of the advantages of source code management. Why should my SVN repository be full of branches for every developer little itch? No one really needs access to those branches, so let's keep them local. Creating branches takes less then a second and adds tons of flexibility.

2) Offline commits. With git (and the like) I have an entire copy of the repository for a given program on my computer. Thus when I'm not at work, I can keep working and doing commits. Then when I get back to work, I can push it up to the 'server'.

3) Better control over commit access. I have work studies and interns. They write code, but I do not want them to have commit access. With SVN their workflow would be:
a) Write all code on their computer without any of the advantages of source code management (no history, no branching, nothing)
b) When finished, zip it up and email it to me for code review
c) I then have to place the files in a work directory for a checkout and commit it.

So here we lose all the history of changes etc. At this point we are treating our source code management as a backup device. It could be replaced with ftp and folders.

4) Merging. Seriously, merging with svn can be a pain in the ass. Compared to git (and the like) merging in SVN seems down right draconian.

5) Speed, because with distributed source code management most of your commits are local they are very fast. Only the push back to the server is slow. With SVN everything goes to the sever all the time.

6) Ability for our developers to create their own workflows. This is similar to the example with interns. SVN has but one workflow.
a) Checkout code
b) change code
c) merge any changes in
d) check in code
With a distributed system there are many ways to setup a workflow. These could be changed on the fly. Developers can checkout from each other to help each other with problems, or to verify code. It allows an easy way to make a single point of entry for commit access, and allows for pretty much any kind of workflow you can come up with.

As an example, on a personal project I was having trouble with some code. I asked a friend of mine to give some input on a better way to solve the problem I was having. He just checked out my wip branch and sent me an email some time later telling me he made some suggestions. I then checked out my wip from his computer and merged that into a new branch for review. After I was happy with the changes he made (and tweaked/commented a few things) I merged that into my wip branch and continued working. I did all that without running a git server at my house. My 'git server' is just a usb hard drive where I keep my projects. With SVN that process would have been a lot more complicated.

One last thing I love about git is the way all it's branches are accessed and stored. I love how you just have one working folder and you can 'checkout' a branch to it as needed. This means I can have 2 or 3 branches that all share the same working folder. It's kinda hard to wrap your head around at first, but it has vastly cleaned up my workspace. It's one of the features that really drives me to git over bazaar.