I started using Mercurial and chose MacHg as my GUI of choice, simply because it was the first thing I found when I googled Mercurial Mac GUI. However, I just recently discovered Murky, and TortoiseHg was recently updated for the Mac. Are there any significant reasons I should choose one over the other, or is the decision simply which application's interface I like the best?
I am the author of MacHg so of course am biased. Re Murky, it hasn't been kept up to date and it will fall over with large scale repositories when viewing history. It has to parse the whole history graph to lay it out (it uses the top level 'hg log'). Through a neat trick MacHg does this incrementally so if you have 200,000 commits MacHg doesn't need to read them all to figure out how to display them it can jump right to the place you are viewing. TortiseHg also suffers from having to read and parse the whole history although it can do this much faster than Murky (since TortiseHg uses faster lower level calls to get the data) (as reported to me by others.)
SourceTree seems like an ok solution. It is supported now commercially by Atlassian who do Bitbucket and they are a nice bunch of guys. However, as of my last test of SourceTree(1.4.3.1) it appears to be limited by the same problems. For instance one test case I use is the OpenOffice mercurial repository which is some 3Gigs with 260,000 revisions. Trying to view the graph for say revision 150,000 is really really slow in these other programs. I quit SourceTree after 5 minutes of waiting.
Also MacHg has some nicer history and rebasing tools if I do say so myself. SourceTree right now has better integration with some of the external services like Bitbucket and GitHub although it is not difficult at all to add repositories in MacHg (simple drag and drop or open, or paste in a string, etc...) Neither MacHg or SourceTree (AFAIK) have support for phases yet but I plan to add these very shortly as I am sure SourceTree will as well. TortiseHg has support for phases I think right now.
And well, I like "look and feel" of MacHg of course :)
You can't go too wrong with MacHg, or TortiseHg, or SourceTree unless you have large repositories in which case I would opt for MacHg for now.
Cheers,
Jason
This question is sort of subjective, but I've found SourceTree to be a good solution for visualizing your working copy. However, for the most part, I just use the terminal to commit/push/pull/update.
MacHg has at least straight forward instalation and Mercurial is integrated inside, what i missing is info, and there is also commandline interface, only documentation is not good enough.
I was in mac-mercurial / python / keyring configuring hell circle, i just new to setup repository for pulls without password asking (where pass is encrypted) from sh script for my build server. MacHg could be the way out, because everything is already integrated in instalation package, except mhg and chg aliases for normal (no MacHG) terminal.
I also missing some info about repository cloning progress, because i cloning 500 MB repository from bitbucket through https take me usually 2 hours. I need to debug if is problem on mercurial, ISP (it should be done in 2 minutes in regard of my connection speed) or bitbucket side.
Related
Every time I was thinking of switching all of our little team's projects to git / github, what pained me was that there didn't seem to be a tool to visualize all this social coding goodness.
When we all start wildly branching, forking and merging, I feel we're going to need a tool that would let us graphically see the full picture of our repository and its multitude of branches, in order to come up with a plan to merge it all back at some point into one and only truth (the proverbial origin/master).
I've tried googling for such a visualization tool on several occasions, but came up empty handed. Was hoping that GitHub for Windows would solve this once and for all, but all it shows is linear history for a particular checked out branch.
What I'm looking for is something akin to what TortoiseHg has - a graph showing all branches and commits. Are you aware of any such tools? (We're on Windows.)
SourceTree seems friendlier than TortoiseGit for the graphs and you can interact with the graph as well.
Stick with msysgit
gitk --all
is what you want. From there you can even checkout branches, reset them, view diffs, etc.
For something quicker, I would suggest
git log --all --decorate --oneline --graph
This gets piped through less by default which gives you good navigation including search.
Another option is just to install linux in a VM (virual box is free) and use tig. You can ssh to the VM so you don't have to deal with the VM itself while using linux.
GitExtensions is your best bet.
TortoiseGit is ok, though in it's attempt to "protect us from ourselves", they hide some of the native power of Git. Fail.
SeeGit is an interesting project from Phil Haack that helps visualize things.
The best tool is the command-line and a quick command like this is probably easiest and most powerful:
git log --oneline --graph --decorate --all
That pretty much would have to be TortoiseGit since you are already familiar with TortoiseHg. (Check All Branches)
Now days VScode has extension called git-graph, which worked best for my needs.
You could use Le Git Graph (read as legit graph), a browser extension that does exactly this, within browser.
Install the extension from here : https://chrome.google.com/webstore/detail/le-git-graph-commits-grap/joggkdfebigddmaagckekihhfncdobff
It will add a new "commits" section to every GitHub repo you open. Open the commits graph and there, all commits across branches will be listed along with the git graph.
Hope it helps!
An upvote would be highly appreciated!
Depending on your push \fetch \ pull habits then you can either use the gitk viewer to see what you know locally (including the remotes you have fetched), or you can use the Network capability on Github to see what it has.
Just select a multi-forked project (with not too many forks;-) and click on the network tab to see how all the other forks relate to it.
Some times you do need to switch fork to get the view point you want, but it's not too much hassle, and for a small team it looks ok.
I have made recent suggestions to Github about selectivity for forks (to down select when there are a lot of forks to display).
First, a confession. In about 10 years of professional development, I've never used a source control system. There, that feels better. My historical setup (as recommended by management, ha!) has been to create dated folders on a server and copy-and-paste my data into it each evening.
I've known for a long time that a much better, manageable solution would be to use git or Mercurial to manage my source but I've never taken the time to learn any of these new tools because myold system has always worked well enough for my needs as the lone developer for every project I've ever worked on.
I have finally change this setup. I've installed Mercurial on my Mac, which after a bit of reading, I prefer over git. As a GUI front-end, I have installed SourceTree which appears to be easy to use and quite friendly. The problem I am having is that I can't find a very simple, straight-forward walkthrough for setting up a server repository that I use for pushing changes to each evening. I'm sure it's there, I just can't find it.
I've honestly tried to Google this, but there is something about the term "SourceTree". I can't find anything useful because half of the information I find is in regards to using git and it tends to involve pushing a project to a site like github.com, which is not pertinent in my case.
Additionally, I have skimmed the Mercurial documentation and I still may not be entirely clear about the full commit/update/push/pull/branch/merge concept. I just want to get something setup rather fast that will back-up and track the changes of my projects, without having to be a source control guru.
How do I setup a simple repository on a Windows network server, and push and pull changes each evening? My company want me to store my data in a personal folder, on a network share that is backed up to tape and is then stored off site.
I'm sure it has to be simple. I just want to be sure that I'm doing it correctly so that in the case that I need to access a back up, it is there and can be easily pulled... or branched.. or whatever.
Well, it depends on the kind of the server you are going to use.
Let's assume it's not a Windows server (just a guess, as you're a Mac user). Let's also assume that right now you only need it for yourself, not for a bunch of users.
Then the simplest way is to use SSH. Suppose the server is server, and you have an account rlh there. You'll need to have a public/private key pair for a seamless access (no need to enter the password on each pull/push). You'll need to install Mercurial on the server as well, obviously.
On the server, create a repo (in your home dir, for example):
rlh#mac$ ssh server
rlh#server$ mkdir myproject
rlh#server$ cd myproject
rlh#server$ hg init
On your machine, clone the repo:
rlh#mac$ hg clone ssh://rlh#server/myproject myproject
The default target will be set automatically, and you should be able to pull/push with no additional configuration.
Feel free to ask if you have a question regarding this.
When searching for hosting solutions, best not to include the term SourceTree in your query — SourceTree is just a front-end tool that is in principle unrelated to Mercurial hosting. That might explain the lack of useful information.
Here is an overview of ways to set up Mercurial servers:
https://www.mercurial-scm.org/wiki/PublishingRepositories
Personally I’m using plain hgweb and that has served me well.
Also I would recommend to consider using a hosting service such as BitBucket or Google Code. It requires much less effort to set up and maintain. Here is an overview of Mercurial hosting services:
https://www.mercurial-scm.org/wiki/MercurialHosting
Personally I’m also considering moving my self-hosted Mercurial repositories over to BitBucket, because of reduced maintenance overhead, and also it has functionality like bug tracker, wiki etc.
I have a question, the answer isn't really hard technically, but I am more looking for the experience of most advanced programmers here.
So like many noobs, I am doing my version control in the crappiest way, which is to copy paste my project directory and rename it with the current date/time.
You will agree that it's a quite limited solution :P
I decided to learn version control system(s), but I am facing many choice, and I would like to know what are the best for your points of view ?
Using Xcode integrated version control (git or anything else), with organizer, cloning, commits from xcode etc. I mean totally or almost controlled by Xcode ?
Ignoring Xcode letting him think there no version control and doing it myself in command line ?
A merge of the two above ? How ?
And then :
Using git ? Github is very popular and powerful, but you must learn git, and learn it hard.
Mercurial ? It seems more friendly.
Something else ?
It would be priceless to have some feedbacks about more experienced people, so that me and many others I hope can choose their paths when facing the VCS wall :-)
Thanks a lot !!!
First: Use a VCS at all.
The rest:
Mercurial is nice, but Apple went with Git for Xcode. So if you want source control integration within the IDE, Git is the best option.
The things I miss most when working with Xcode & Mercurial are the "Modified" indicators in the source list and the integrated diff-viewer. (Which is pretty good in Xcode IMO)
The actions you perform in the Organizer are a bit limited at the moment, but you can always fall back to Terminal.app for that.
I can only recommend git. Merging is easy, I remember the days when a merge conflicts occured with SVN, it was pain, horrible pain to resolve those. You can easily start a local repository with git, especially if you are the only one developer.
Have a look at Which SCM system to use with Xcode 4 for a lone developer?.
I suggest some reading on git for the beginning:
Git in five minutes
Git Community Book
The Thing About Git
Take some time to invest in learning the basics of git, it's absolutely no rocket science to get you started on basic usage and you will benefit from it right away. Once you know the basics of git, you aren't locked into another tool wrapping git, you can use git if there are some problems with XCode. Also, git is available for several OS so the knowledge you gain about git will not go away if you move between different computers that have different OS.
Here are my best of bookmarks for git:
http://www.delicious.com/Ralphtheninja/bestof+git
I've had good success with SubVersion.
Intro
I've used SVN before, back when I was working as a solo programmer, just to keep an offsite record of what I was doing, so I kind of know about ideas like "repositories" and "commits" and the like, though not much more than that. "Branches", "merges" and "checking out" are, sadly, a mystery to me.
I want to start using Git because we've got a couple of guys who work away from the office and they have complained that they sometimes can't get through to some other version control systems because their IDE integration causes them to sulk and fall over when they get out of contact. Git's idea of "Every working directory is a repository" seems like it should go some way towards solving that.
Anyway, I've downloaded the "Git Extensions" to add The Shiny to the Windows context menus, etc. and I've found that I really have no concept of how I'm supposed to use this to control my versioning. Not finding anything obvious after a google search, I present the following theoretical scenario to Stack Overflow in the hopes that someone will tell me what to do, in small words:
Scenario
I have three projects. One project, ProjectReuse is used by the two other projects (ProjectA and ProjectB). Various people in the organisation will need to edit the code for each project, using Visual Studio 2010.
I have three folders on my desktop, labelled "ProjectReuse", "ProjectA" and "ProjectB". I've got the Git Extenstions window open. A cow, wearing a Santa Claus hat, is staring at me.
Questions
What do I do now to create the repositories in such a way that several people (including those pesky not-always-on-site guys) can access a repository when they need to, on-site or off, with or without a permanent connection to our servers?
When the first guy needs to edit a file, what does he need to do? Check out? Branch? I have to explain this to the other team members and I'm a bit wobbly on these concepts, myself. I've only used version control for my solo projects before.
Wheedling and excuses
The first "how do I set this up?" question is what I'm most interested in, but I figure if I'm going to ask for the idiot's guide, I might as well ask for it to be as useful as possible for the next idiot who stumbles onto this question. I'm not looking for particularly in-depth answers, here; I just haven't got any clear picture in my mind of how a multi-user version control system works. Once I've got that in mind I should be able to put the rest together by myself.
Ok, let's get the first thing about git straight. Git is distributed. Repeat this to yourself as many times as necessary: there is no central server, central repository or indeed anything central. Completely in contrast to SVN, you are not all accessing one repository (nothing central).
What you do is create a repository somewhere. Then everybody else clones (copies) it. Now everyone has their own copy of the repository and can do with it as they wish. Branch names don't even need to be consistent across repositories although many people do this as it helps.
So, how do you set it up? You init a repository then everyone who wants it clones it. In your case, I'd recommend each project have its own git repository rather than lumping all three together.
But but but how on earth am I supposed to manage a development team, I hear you say? Never fear. I said there was no central repository, but that doesn't stop you designating one of the repositories to be the release repository, and another to be the experimental or whatever.
What you need then is a workflow. Typically, what you do is create said release repository and then say: "everybody pull from the master on here". This represents your latest "stable" release. Now you tell everyone to branch from here and develop their new features. They do this. As these get done, you ask people to merge their changes back into their own master or wherever, then you, the release manager, pull from them (probably into a development branch but you could well do it into your release master because it is trivial to reverse commits). The next person then updates their master and does their merge. They resolve their own merge conflicts etc, and so on until you have all the features you want. You do your testing etc then the release repository really does pull all of that into its master.
In practice you might do many different things. For example, if you have a lot of people you're going to need quite a lot of communication going on, because if lots of people make incompatible changes to your shared project there's going to be a few merge commits. To avoid this, users can pull/merge from each other or use a local "shared" repository.
It does work.
As said by Ninefingers, just init a new repository and let others clone it. Keep in mind that when you want a public (or central) repository, create a shared repository and not a private repository. The easiest way is to create a personal repository first, and than clone it to a place (e.g. network share) where everyone has access to as a shared repository.
I created a few video tutorials for Git Extensions here:
http://code.google.com/p/gitextensions/
The video tutorials are a bit old and not very good since I do not have a mic or any video editing skills, but it should be enough to get you started.
Good luck!
I'm coming from a TortoiseSVN background and decided to give TortoiseHg a try. One thing I got really used to with TortoiseSVN was the SVN Repo-Explorer, which worked quite similarly to Windows Explorer. However, when I tried to use TortoiseHg's Repository Explorer, what I got was something else, it was more like TortoiseSVN's Show Log. It showed me what the recent commits were and what files were changed and even had nifty graphs. However, I'm still left wanting for TortoiseSVN's Repo-Explorer.
Does TortoiseHg have anything like this? How am I supposed to poke around the Repository if I can only view changed stuff?
I might be wrong as I have little experience with Hg myself, but I believe the reason TortoiseHg doesn't have a repository like its SVN counterpart is because Hg is a distributed VCS instead of a centralized VCS like SVN. So, the actual repository is your "checked out" copy. When you commit, you commit to your local repository, then you can push changes to other people or locations (such as google code, or your team mates). There are actually multiple different repositories for a project located in many places, instead of a single one, so there isn't really any meaning to "exploring the repository". The best you can do is check for incoming change-sets and view your local repository (using windows explorer).
This is mostly my reasoning based off a little experience with both. I might be wrong, but I hope this sounds reasonable.
This article might help clear it up: Distributed revision control. It took me some time to wrap my head around the idea of a distributed VCS too. In a nutshell, it's kinda like emailing your changes to your team mates. Everyone has their own individual repository, and each updates their own repository by getting change-sets from others.