Git or Mercurial
Monkey Archive Forums/Monkey Discussion/Git or Mercurial
| ||
| I've been using Subversion for my projects for years now, and have finally decided to take a proper look at Distributed Version Control Systems ... but which one? Without flaming or being fanboyish, can anyone give me a good reason why to choose Git over Mercurial, or vice versa? |
| ||
| @Kalakian: I've just got Taiphoz using source control, so stop hassling him to use a different one while he's getting used to SVN :P Nooooo stop him now! Getting used to Subversion is a bad thing! XD To me, Git vs. Mercurial is six/half dozen. I chose Mercurial because: a) A guy at work recommended it. b) Another guy at work gave a one hour session on it. c) I find TortoiseHg to be nicer than TortoiseGit, and I haven't seen any other decent GUI tools for Git. Knowing the command line parameters for Hg/Git is nice, but I'd rather do two clicks and get back to coding than to start up a command prompt and type stuff. d) At this point in time, I don't see any reason to move to Git when it seems very similar. |
| ||
| I can't really give a detailed response but I've gone with Git and did so once a decent Windows GUI was introduced (which was quite recently by Github themselves). http://windows.github.com/ Git does what I need, and the GUI is very easy to use. |
| ||
| Ok, you've both given reasons that can be summarised as "just because", which doesn't help me much :P I should point out that I'll be using the Tortoise client whichever one I do go for, because it's just superb ... TortoiseSVN, TortoiseGit and TortoiseHg already installed. |
| ||
| Yeah I am enjoying the tortoise client as well, but that does not really go for much because I don't really have any experience with anything else. I actually really hope that no one answers you with a really good reply derek cos Iv just spent the night porting and adding "!ALL!" my monkey max and b3d , php ........ etc projects to be SVN managed. Oh and I installed that Visual SVN server, which is so simple to use it's kinda mind blowing. <whisper>so if you have a really good reply.... GO HOME!</whisper> lol |
| ||
| Both Github and Mercurial are great and MUCH BETTER than SVN in absolutely everything. I would go for Mercurial becouse: -It's easier to find complete how-to documentation and guides for beginers. In fact everthing can be seen here: http://hginit.com -From my experience, it seems to be a bit faster than Github -Github documentation is spread and not always up to date Anyway, you would be choosing between two great technologies and for a project of this size where branching should be allowed, encouraged and handled properly, staying away from SVN is a godsend. |
| ||
| I'm happy to go with either. I only have preference to Hg because I have it installed. ;) |
| ||
| ziggy that HG init link instantly put me off, years ago I did nothing but work in cli's but now I really cant stand them and feel that if I have to drop down into shell or command that the application I need to use has failed in some way. Namely having a good working GUI to use. It's 2012, nothing should be done in a cli, and anything that actually needs to be done in a cli should be done behind the scenes away from the user. My own personally opinion, but unless Mercurial or Git has a nice working front end I wont even give them another thought. |
| ||
| @Taiphoz: There's nothing forcing you to use the command line, but it's recommended that you understand the tools you use and using a Gui frontend that prevents you from learning what you're doing is inmediatly fast but counter-productive in the long run. It was just an advice. Take it or leave it. Tortoise for Mercurial has a reputation of working well, but I would never seriously recommend staying away from the console when working with any version control system. Specialy on 2012. My own personally opinion, but unless Mercurial or Git has a nice working front end I wont even give them another thought. But what are the benefits of sticking to an old-dated unproductive and branch unfriendly system like SVN. I thought it was 2012!! :DAnyway, it's an advice, you're free to ignore it if you prefer to stick with SVN. I personaly won't be prociding code for the project becouse of current workload BUT I would love to participate in any other iteration of the project. It looks like a very nice idea. I see it more or less like SVN is a Gosub, while Mercurial and Github are propper function calls. |
| ||
| I have perfered SVN because of their Windows integration - called tortoise. Well guess what. GIT and Mercurial both has Tortoise clients these days. So these days I have all three installed (because as a programmer you will inevitably end up wanting to look at code from all three systems) SVN is what I am used to. I never got the benefit of HG or Merc because they trade the most valuable thing of ALL friendlyness for performance & features. So on a feature stand-point, they win. Speed, they win. Optimized Disk Useage, they win. These days though (if you use Tortoise) the user friendlyness is the same basically. And SVN do create problems from time to time, especially on bigger projects. It can be a mess. However before commiting code on HG it is essential to not use the SVN way of doing things - because then they are just worse. But if you work the way they intend I only see benefits. Bottom line - The downside is that almost none can easily explain HOW TO use Merc/HG. It is as simple as SVN with the Tortoise interface tough. I would, but don't feel like I have time now to write a proper guide - maybe we can do this in this Thread. Because at the end of the day if you combine bitbucket (FREE repository in the cloud online, unlimited commercial projects, but costs when you are more than 5 users) or googleCode (for OpenSource project only) WITH HG/Merc then it is so far the most awesome CodeHandling I know. Links: HG http://tortoisehg.bitbucket.org/ GIT http://code.google.com/p/tortoisegit/ |
| ||
| I just realized that Derek (Kalakian) said he had tortoisHG and Git, so my previous front end comment is kinda void now, and I have now downloaded both those clients. I am reluctant to install them however, I don't fancy having a huge context menu with three different source control systems in it. @Ziggy, yeah of course it's old but its new to me, and I'm still learning it and have as of yet not found any problems with it, so thus far I am happy with TortoiseSVN and VisualSVN to manage my code. NOW.. For argument's sake , lets assume I wanted to try something new, like Git, or Merc, would it be possible for me to convert my SVN repositories over to both of those systems or will I need to make new repositories for each of them. Also I am using VisualSVN windows svn server for my own work, does Merc and Git have an equivalent ? |
| ||
| Thanks for the answers everyone. Looks like I'll be flipping a coin between the two of them as all answers just seem to be personal preference or "yes, use one of these" :) I do like SVN's simplicity and still think it is really useful for small team or individual projects where de-centralising is just an unnecessary complication. I agree with Taiphoz that CLI shouldn't be used much nowadays except for at server side where it is essential. Whichever I go for, I'll be using the Tortoise client and only dropping down to CLI if I'm doing something a bit obscure and not in my general workflow. From what I've seen so far, Mercurial seems to be the more straight-forward, but the branching isn't as good as Git. What do you Merc users think of the branching? |
| ||
| Here's an example of how I'd like to use branching, to give you a better idea: Project reaches V1, so create a branch for V1, keeping the trunk for continuing on towards the next version. While working on V2, I get a bug report for V1, and after testing, I find it's in V2 as well. I fix it either in the trunk or the V1 branch and push it to the other version, without pushing new features from the trunk into V1. ... Please bare in mind that I haven't really used branching before, so if that's really not how you would use it, fair enough, but how would you use it then? |
| ||
| the way I was thinking that branching would work is that if I am in the middle of code, and have options as to what to do next, I might two or three beaches to code and est those changes, if I then decide that branch four's code works the best I have a way to push that into the trunk. or is that not how it works ? |
| ||
| @Taiphoz AFAIK experimental branches like you describe are quite common, so I would like to be able to do this as well. |
| ||
| SVN does not do this tho right ? which I suspect is what people have a gripe about. or am I wrong ? |
| ||
| SVN does do branches. Creating the branches is simple, but there are horror stories of when it comes to merging the changes. If I could do both the above examples of branching with SVN without too much hassle, I probably wouldn't even bother looking at Git or Mercurial |
| ||
| Definitely Mercurial! |
| ||
| Samah : I was wondering you like git over svn why does diddy use an svn repo and not git ? |
| ||
| +1 for hg (Taiphoz, apparently therevills won't let him switch...) :-) |
| ||
| Just saying which one you prefer doesn't exactly help ... I asked why to go with Merc over Git or other way round. I can easily flip a coin and go with whichever one, but I would rather make an informed decision than leave it up to chance. |
| ||
| SVN does do branches SVN do not do branches, SVN fakes branches and then breaks merging. It has no control on changesets, it just compares files.Say you move a function from a file to another file, while someone else is modifing the function body. The merging result? On SVN you won't be able to merge properly, and you'll have to repeat everything by hand. (Now try to do this with Tortoise). On Mercurial or Github, as the changesets are stored, it will know that the function has been moved and ALSO that the function has been modified, and as a result, it'll merge properly. That is, it'll be moved and modified. That's real branching. What SVN does is a bad joke in comparison. |
| ||
| @ziggy not really the point though. I've already decided to look at one of the DVCS because I know svn is limited, but I don't know which one to use. I have came across problems like that before using tortoise, and if using a decent diff tool with it, it is manageable (albeit clumsy). SVN kinda does branches then ;) Anyone able to comment on the branching examples that Taiphoz and I gave above, and whether they would work well in Git or Mercurial? |
| ||
| I have been on BIG project and merged BIG branches in SVN - it is a Nightmare! I would not wish anyone the same. I have not done that in GIT or HG, but I'd be much more relaxed branching those since they apparently are built for that. That along with speed is my reason for now moving everything to HG from SVN. Note: I still have most old things in SVN, but I see little reason not to move them over to HG. On the question "Can you convert from SVN to HG/GIT" - Goto Bitbucket.org, create and account - import your SVN (you now have a HG copy) and your are DONE with all your source version controlled and backed-up in the Cloud. I have only done that on small projects, but so far I'd recommend it to anyone! I love it so far! Please be kind to let me know if it is too good to be true :) |
| ||
| been reading all day long , on merc vs git vs svn .. and found an interesting read that some of you merc and git fans might be interested in, http://www.readwriteweb.com/hack/2011/10/can-bitbucket-challenge-github.php Its probably where I will end up since it will import my current svn, and can be used for git as well as merc. |
| ||
| I went through the same eval process ~2 years ago after using SVN for a decade. I choose bitbucket with merc and have been satisfied ever since. |
| ||
| yeah it's not the most popular git def has a bigger community, but thats not really an issue for me, so the free private repositories and its ability to use gir, merc and subversion is what is making me really consider it. |
| ||
| I'll probably create a bitbucket account and start a merc and git repos for a test project, see which one I like the best. |
| ||
| I think at this point and after hours of reading blog posts, guides, tutorials and just about everything in between I still feel a little lost when it comes to Mercurial and Github. But, at this stage I think its a 100% given that I will need to install both as well as keeping subversion in, my only real important decision now is which of the three I am going to use to manage my own code and projects. Still on the fence, but leaning toward mercurial from what I'm reading it seems the most user friendly of the two. |
| ||
| @Taiphoz: Samah : I was wondering you like git over svn why does diddy use an svn repo and not git ? Because therevills set it up originally and he's a Subversion fanboy. :) |
| ||
| Maybe we could bring therevils back from the dark side of the force? |
| ||
| LOL! NEVER!! Actually the main reason why Diddy is using SVN is because I set it up before really understanding Hg (and thats the same for Samah too). I'm reluctant to change now as other users of Diddy will have to change to Hg too... |
| ||
| DAMN IT therevills, I was holding you up as MY ONLY!!!!! example of some one who likes subversion, you have just blown up my little thervills bubble... HUH! thanks mate lol |
| ||
| I have finally decided to use Mercurial for all my own work, and I doubt I will be changing away from it to anything else now, the similarities between git and mercurial make it that using either is simply a personal choice and not one of features. That being said there are a few key things that swung this in Mercurial's favor for me, the first is Bitbucket and the fact that it's free for teams of 5 or less, with unlimited space, and unlimited private and public repositories, and that's a major plus to me. The other thing was that all the guides and tutorials that I read yesterday, and I got through a lot of them, the ones for mercurial all just seemed to be shorter, easier to understand and more straight forward while those for git seemed to be a bit of a dry LONG! read. I have installed all three systems and will use all three from now on where needed, but for my own projects it will be mercurial that's more dominantly used. |
| ||
| Remember to commit early and commit often :) |
| ||
| HG for me all the way. TortoiseHG and its repository workbench is a godsend. |
| ||
| Have to agree I am enjoying it very much. Still a bit fuzzy on how branches work tho. |
| ||
| HG feels so fast, however I'm still a bit lost on how to actually do an proper update. What I don't get is how to switch current version after doing a pull. I think I get the theory, but not yet the user interface. And what does "Update" do, if Pull is what gets the data from the server? I'd love to see a dead simple. Monkey & Mercurial + Tortoise tutorial. And I'm all OK with you moving Diddy to HG, just write a 1,2,3,4 list of how to get updates in HG :) |
| ||
| I'm working on a document with a simple set of tests for mercurial/git. It's not gonna be a tutorial per se, but it may help ... assuming I can get it working and finished :) |
| ||
| What I don't get is how to switch current version after doing a pull. I think I get the theory, but not yet the user interface. And what does "Update" do, if Pull is what gets the data from the server? "Pull" brings changes from another repository into your repository. It doesn't alter the working directory files by default. "Update" brings the working directory into line with a particular revision (the tip by default). You can do a pull+update in one operation on the command line and most UI clients if that's what you want. |
| ||
| In addition to what muddy_shoes says, or to simplify it: pull :Make my repository aware of any changes available on the remote repostitory update: apply latest known changes to my local working repository (usualy this merge what's required to be merged) This is more or less the oposite to commit and push. |
| ||
| I've been doing some experimenting with Mercurial, especially branching, and documenting my findings as I went along. In case it is of interest to anyone, here's what I have so far: https://dl.dropbox.com/u/49903113/DVCS%20Testing%20V1.pdf I'll tidy it up a bit, add in my findings using Git for the same experiments, and maybe even turn it into a detailed tutorial ... at some point! |
| ||
| Kalakian: I'm not sure what your problem is with that first red highlight. I think you might be misunderstanding how branches work. Your local changes aren't "lost", they're simply a different changeset. If you look in the workbench for repository 2, you should see something like this (ignore my keyboard spam commit messages): Where revision 2 is from the first repository, and revision 1 is the local change that has yet to be pushed. Nothing is lost, it's just not the current changeset. No merge should happen unless you explicitly tell it to. Your head is still in CVCS-land in that case. Edit: In this example, you would update to revision 2, then right click revision 1 and choose Merge with Local. Resolve any conflicts, then commit. It should now look like this: 2nd Edit: If you push from repo 2, then pull to repo 1, you should get this: Then update to revision 3, and it should look pretty much identical to repo 2. 3rd Edit: An automatic merge will only happen if you have new/deleted/modified files in your working directory when you update to another changeset. 4th Edit: Note that revision "numbers" are generated locally for the sake of display. The same changeset may have a different revision number in another clone, but internally it has the same ID and the graph should look identical per-branch. Notice here that the changesets with revisions 1 and 2 are in a different order in each repository. This doesn't matter because the changesets aren't related until the merge. |
| ||
| @Samah. The first red highlight is to indicate that things didn't happen as I expected them to, not necessarily that something went wrong. I've been using SVN for years, so there's bound to be some things that don't work the way I expect. I do find it a bit strange that when I do an update, it just overwrites the changes in my working copy, but not my local repository as you point out. That confused me a bit, which is why I highlighted that bit in red and found a solution to it below, which is similar to yours. Thanks for explaining it in such detail though, it helps to see what is supposed to happen, for me and others. |
| ||
| For anyone coming from SVN it is highylu recommended to read this: http://hginit.com/00.html |
| ||
| @ziggy I have read that, it's resonably helpful. The bit I didn't pick up on straight away is that you're not given a warning about the merge until you try a push, rather than an update. |
| ||
| @Kalakian: ...as I expected them to... Gotcha. :) @Kalakian: I do find it a bit strange that when I do an update, it just overwrites the changes in my working copy, but not my local repository as you point out. The term "overwrites" that you're using implies that your modified files have been lost. You should probably think of "modified" as meaning "uncommitted". If you have a clean working directory when you update (ie. no added/removed/modified files since the last commit), all your code is still there, just not the current changeset. It's a strange concept at first, but it's nice to know all your code is safe within one changeset and won't have any weird automatic merging problems when you pull and/or update. You only need to update to another branch if you want to start working with that branch, or if you want to merge the latest changeset from your own branch into the other. |
| ||
| I think I might skip this branching lark until I get more familiar with the basics on it. The concept seems easy enough bit how its actually implemented and how it actually works seems confusing to me a still, but I will come back to branching like I said, once I have a good basic working understanding and some time spent actually using mercurial and hg. |
| ||
| The bit I didn't pick up on straight away is that you're not given a warning about the merge until you try a push, rather than an update. That's expected. You're mixing two different "push" versions, but it should be perfectly ok. The merge won't overwrite the changes on you last local comit, it'll mix them properly with any other changes done by any other contributor (that's why this kind of things are for :) |
| ||
| Finished running the same tests using TortoiseGit, and have included a summary of significant differences that I noticed between the two of them. https://dl.dropbox.com/u/49903113/DVCS%20Testing%20V2.pdf Now, if only I could decide between the two of them, lol |
| ||
| Finally made my decision, I'm going with Mercurial. Thanks to everyone for all the help and suggestions. I had a look at TortoiseHg's settings (and done some Google'ing) and was able to configure it to better suit my desired workflow. I've taken note of the changes and why I made them in the third version of my test document, just in case it helps anybody else out. https://dl.dropbox.com/u/49903113/DVCS%20Testing%20V3.pdf If I do make any more changes to the document, I'll be removing Git and explaining why I'm performing each test, so it may be used as a tutorial ... but in the meantime, I have several projects to convert from SVN, and I gotta setup my Server for Mercurial, and link it into Redmine, and ... The fun never stops :P |
| ||
| Kalakian: If you're planning on doing an automatic conversion, take a look at svnsync and the hg convert command. It took me about 30 minutes to do a local read only clone of the monkey touch repository (my work's internet connection is terrible), and less than 10 seconds to do the automatic conversion, which retains changes and commit messages. |
| ||
| @Samah cheers, I'll give that a try. Tibit also said above that bitbucket can convert your SVN repositories, so I'll try that as well, thought it probably just uses one of those commands under the hood anyway |
| ||
| Yeah use bitBucket if you can! Works great :) I'd love to see a step-by-step tutorial on how to deal with Mercuirial and Monkey. Samah great with Screenshots like that. However the aspect I feel not sure about is merging, branching. |
| ||
| I avoided conversion with bitbucket since it doesn't retain your history. Samah's suggestion of hg convert worked great though |
   |