Hi Hugin developers, Recommended reading (for everybody, not just developers) <http:// hginit.com/>
For years Hugin lived in Subversion (after being migrated there from CVS, but that's pre-history). SVN was the state of the art. It has worked well for the project as we learned to use its features and deal with its limitations. In the meantime a new generation of distributed version control systems (DVCS) has matured and is now the state of the art. There are at least three contenders: * bazaar (bzr), used by Pablo recently for the patent-free control point detector * git, used amongst others for Linux kernel development. On the Hugin project I know Gerry Patterson and a few others interface git automatically to Hugin's SVN. * mercurial (hg), Andrew Mihal migrated Enblend-Enfuse from CVS to hg a year or so ago. The one limitation of SVN that DVCS improve dramatically on is merging of (development) branches. Conceptually the current generation of DVCS are very similar and share the major features set. I personally favor mercurial because I found GUI integration (such as TortoiseHg, similar to TortoiseSVN) to be more mature. Recommended Hg tutorial (a well spent 30 minutes reading of nicely illustrated text by Joel Spolsky): <http://hginit.com/index.html> *PROPOSAL* I've been toying with Hg, and I herewith propose a (partial) switch to Hg, specifically for the *development* branches. This would make the management of multiple codelines easier. Before migrating, the following criteria must be met IMO (feel free to discuss / add): 1. there has to be an easy two-way interface (from SVN to Hg and from Hg to SVN), at least for the transition period. During such a transition period (which could extend indefinitely if we find that the hybrid SVN/Hg model works best for the project), developers would start their branches on Hg (see instructions below) and from time to time push back changes into SVN. The release process would still run like today, on SVN. SVN would be reduced to "trunk" and "release". 2. the tools to access the new DVCS must be at least equally comfortable on all currently used platforms. This is the advantage of Hg, even if the other tools have caught up quickly. 3. all the revision history must be preserved in case of a complete migration leaving SVN behind. This is the point at which I am currently stuck. There is at least one manipulation in the Hugin SVN repository at revision 2494 that breaks the import of trunk. This is when Ippei's development branch (from GSoC 2007) became the "new" trunk. Maybe there will be a way around it by trying to migrate the whole repository and not just Hugin's trunk. I'll look into that when I have time. The process of importing a full history is very slow (and still going while I write this). Here is what I did in Kubuntu 9.10: 1. INSTALL THE TOOLS $ sudo apt-get install python-setuptools $ sudo easy_install hgsvn 2. IMPORT FROM SVN $ hgimportsvn https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk/ wait a loooong time for the import to complete 3. FETCH THE HISTORY $ cd trunk $ hgpullsvn wait an even longer time while the whole revision log slowly scrolls under your eyes. In *theory* I should be able to make changes to the code using Hg and then push them back into SVN with the following command: $ hgpushsvn I have not tried it yet because I have nothing to commit at this time. hgsvn is documented at <http://pypi.python.org/pypi/hgsvn> The way I understand it now (not completely yet - more investigations required) this interface is enough for current and future changes as long as we keep SVN as the master repository. The Hg repository can be used locally (faster, more atomic commits, less fear of breaking things) and maybe even pushed to Hg on SourceForge. Developers (e.g. GSoC students) could maintain a backup of their work on an Hg repository on SourceForge, leaving SVN uncluttered for integration and distribution work. if the problem of hgpullsvn starting at revision 2495 only is solved (I think it will be if I pull the whole repository rather than trunk only, and after pulling clean up the folder structure), then we could potentially migrate Hugin completely to Hg if there is a wish to do so. For now I'd suggest to stay with the best of both world, Hg for development, SVN for release and distribution. There are a few different projects all living in the same Hugin SVN repository: * KimageFuser * autopano-sift-C * hugin (Hugin itself) * htdocs (the Hugin website) * libpanorama * panoglview It would make sense IMHO to have a separate repository for each and every one of them. If there is consensus, I can start migrating the smaller ones and thus gain experience toward the migration of Hugin itself. What do you think? 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
