Hi Ken, On May 20, 1:05 am, Ken Turkowski <[email protected]> wrote: > There are some compiler problems on the Mac, and I have a fix for it, so > please sign me up for source access: > kturkowski
done. thanks for helping out! > Mercurial looks suspiciously like git tools of the same generation. Add Bazaar (bzr) to them as well. It could have been any of them. Mercurial (Hg) was the one that had more mature GUI clients on multiple platforms. Git depends on the Bourne Shell and Perl for scripting, while Hg (and bzr) use Python. Bzr came relatively late to the party and has slightly less support from project hosting sites. In the end they are all pretty much equivalent and it is easy to juggle between them. I've known many developers who for the past 2-3 years had overlaid one of those three tools on top of Subversion (SVN) - committing to the central SVN repo revisions that they developed on their local check outs managed with git or Hg. When I looked into this trio I also tried to convert the Hugin SVN repo with many of the available tools for all of them and in the end Hg was the one that worked best for me. <humor>And on the command line hg is one char less to type than git or bzer</humor> > Git worked fine most of the time, when I was the > only one working on a file, but it was hell when several people were working > on it simultaneously. Strange - git is used by very large scale projects without significant problems. Also the concept of simultaneous work shouldn't be critical since these tools are designed for asynchronous use. May be more of a local implementation problem than a flaw of git itself. > With CVS, SVN, and P4, I had no problems by doing > frequent updates (4X/day) and checkins at the end of each day, but with Git, > I'd occasionally waste a couple of days trying to check stuff in. Conceptually, the checkins of SVN are equivalent to checkin+push with hg; and the checkouts of SVN are equivalent to pull+checkout with hg. Only pull and push are network operations and only they may be affected by network conflicts or scalability issues. Checkouts and checkins are all local to your machine. If they fail, it may be a problem of the client used. Harry can give you more details about the client he uses on OSX. On Windows I had good experience with TortoiseHG - but I have not used Windows for more than six months now. > I missed the beginning of this thread. How did you happen to choose > Mercurial? Some devs were already using a distributed revision control system (dRCS) on top of SVN. I got to use git during last year's GSoC - Leon ported FreePV to the VLC media player and I co-mentored. It blew me away how much easier it is to branch and merge compared to SVN; and how much more responsive it is to check out / switch branches (no wonder - the whole repo is on the local HDD, disk access is the limit rather than network access for SVN). So I did some research, got community support, we identified and solved the issues, identified the optimal time for the switch and did it. I'm writing up more info on my blog. here is the first installment: http://panospace.wordpress.com/2010/05/19/svn2hg_part1/ > What is the best mode of development? At the beginning of the work session: * If you are online do `hg pull` if connected to the net (but it's not tragic if there is no network) * do `hg co` right after pulling or if you want to work on a different branch During the work session: * edit the code * do `hg ci` after every change and document it in the commit comment. You can commit often, it is faster and more convenient than with SVN because it is not dependent on the network. *important*: a commit is only local, on your HDD. To be equivalent to an SVN commit, you also have to push it (see next steps) At the end of the work session (or when you've added enough change that you think is worth backing up / pushing to other developers to try): * do `hg pull` again * do `hg co` again * if necessary, solve conflicts / merge back to the branch you intended your change to go to. Because of the asynchronism it is possible to unintentionally produce an extra branch - in fact, conceptually every changeset can be seen as a branch. You can see the status of your local repository with `hg view` (you need to enable the hgk extension with a line `hgext.hgk =` in the [extensions] section of your ~/.hgrc file. * do `hg push` to push the changes that are currently still in your local repo to the global SF repo (or to any other repo that accepts changes from you). the conceptual difference from SVN to Hg is that the network operations (push/pull) are separate from the revision operations commit/checkout we've already experienced some network slow down with SF (Thomas had a two hours initial pull, while I had a three minutes one) but overall the system is robust, stable, and ready to take your commits. enjoy! Yuv -- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx
