Hi Yuv et. al. Of course I don't want to stand in the way of progress -- as if that were possible :-< -- so I shall also try to learn Hg.
What has happened to the idea of keeping (past and future) releases in the SVN repository? I thought that was a very good plan, for two reasons: 1) It gets the released code out of the developers' sandbox, a basic rule of good S/W engineering practice -- if you let the developers mess with released code, they will break it. Released code needs to adhere to a higher standard of buildability and documentation, and be carefully crafted in ways that are not relevant to developers' needs, as anyone who has actually assembled a release can attest. 2) It validates lots of existing documentation about how to build Hugin, and many existing build setups. It is important, I think, that the project should be as helpful as possible to people who just want to build (and distribute) stable releases -- Linux packagers, for example. A separate, clean releases archive would help there. An SCCS can be just as valuable for constructing releases as for leading edge development. The fact that Hugin releases have so far not lived in SVN is probably a consequence of the principle cited above. But with the migration of development activity to Hg, why not use the SF SVN for publishing stable releases? Regards, Tom On May 10, 9:28 pm, Yuval Levy <[email protected]> wrote: > On May 10, 2010 02:15:33 pm Thomas Modes wrote: > > > I tested your hg repository on windows. First simple tests were sucessful. > > thanks, Thomas! and thanks to Lukáš too! > > this is better news than I expected. Unless somebody objects, with a little > bit of more testing we could move to Hg on SF this coming weekend. > > Since we retain SVN read-only, nothing will get lost anyway; and the > manipulation of an Hg repo is very flexible. Theoretically it is possible to > replace the big single merge commit of a development branch into trunk with > the whole history of the branch itself by running `hg convert` on the branch > itself and using a combination of splicemap and branchmap when hg converting > two hg repos. Not that I think it makes sense: History is enshrined in SVN. > > BTW, if you look at the file .hg/shamap in the Hg repo you'll find the mapping > of converted Hg revisions to converted SVN revisions. > > > Attached is a patch for the CMake system to work with mercurial (idea > > taken from enblends cmake system, thankes Kornel). > > good stuff, thanks! I think we're good to go as far as the development branch > is concerned. We'll need to re-think / adapt the release process and this can > be done during the next release cycle. > > Then there is the whole wiki documentation to update. > > > For subversion I > > added a warning message in preparation for switch to mercurial. Because > > of the change from an incremental number to SHA1 hash, some little > > changes to source code were necessary (some older code were dropped). > > good. I think it makes sense to make a few last commits to SVN: > > 1. intentionally break the CMake build - terminate it with a warning that > "development has moved to Hg and the code being build is most likely outdated" > - if somebody really wants to build older code from SVN, they will know to > bypass the warning or check out a previous version. > > 2. add a text that pops up every time Hugin is started saying "this version of > Hugin was built from Subversion after development has moved to Mercurial. It > is most likely outdated and not what you want to use. Go > tohttp://hugin.sourceforge.net/for a better version". > > 3. add a big top level README_FIRST.TXT file saying that "development has > moved from this SVN repository to Hg. You are most likely better off fetching > the Hugin source code fromhttp://hugin.hg.sourceforge.net/hgweb/hugin/hugin/"; > - the URL currently shows an empty Hg repo. After migration it will be the > officially sanctioned Hg repo. > > After all of this is committed to SVN, I will lock down SVN to be read-only; > run the conversion process; push the new Hg repo to Sourceforge. There will be > a few hours without repo in between, and if developers have some pending > changes against the SVN repo it is easier for them to commit them to SVN > before I lock it down. Although it should not be too difficult to simply copy > the changed source files into a fresh Hg checkout and commit to Hg. > > > Short test: browsing in history works, first commit with update of cmake > > worked also. Old braches are also shown, but not tested local branches yet. > > anybody else can report a test? ideally a completed build with the patch > published by Thomas? does the Hg repo work well on OSX too (Thomas covers > Windows and I cover Linux)? > > > Concerning keywords, maybe we should drop this concept and use hg to > > keep track of changes, as in your link mentioned. > > I have not had the time to read this part in detail and understand the > consequences. What I do understand is that if we really need keyword > substitution, it can be retro-fitted with relatively little effort. Currently, > a checkout yields the $Id$ placeholder for the keyword. Not a critical problem > IMHO. > > The big question right now is: if there is somebody who sees a show stopper or > any reason not to proceed with Hg, please say it now. Once the GSoC students > have launched their respective projects on Hg it will be a significant effort > to get back to SVN. Personally, I think SVN has served us well and it is time > to thank it and move on to Mercurial for the development branches. > > 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 athttp://groups.google.com/group/hugin-ptx -- 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
