From: D M G. <dm...@uv...> - 2011-02-09 05:49:24
|
I finally got access to the shell at sourceforge and created a repository for the mercurial code: I created the repo last week, so any changes since have not been reflected here. I'll take care of them. Please don't use the SVN repo any more: You will notice that I started a branch to add command line options to PToptimize. hg clone ssh://USE...@pa.../hgroot/panotools/panotools/libpano -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Thomas S. <tks...@gm...> - 2011-02-09 14:28:04
|
Hi Dan On Wed, Feb 9, 2011 at 12:49 AM, D M German <dm...@uv...> wrote: > > I finally got access to the shell at sourceforge and created a > repository for the mercurial code: > > I created the repo last week, so any changes since have not been > reflected here. I'll take care of them. Please don't use the SVN repo > any more: > OK > > You will notice that I started a branch to add command line options to > PToptimize. > What are your plans for PToptimize? I've been thinking it could become a good tool for lens calibration, if we add some more general lens models to libpano. Those could easily be invoked via new PToptimize options. Regards, Tom > hg clone ssh:// > USE...@pa.../hgroot/panotools/panotools/libpano > > > > > -- > -- > Daniel M. German > http://turingmachine.org/ > http://silvernegative.com/ > dmg (at) uvic (dot) ca > replace (at) with @ and (dot) with . > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > |
From: D M G. <dm...@uv...> - 2011-02-11 08:23:22
|
Thomas> What are your plans for PToptimize? I've been thinking it Thomas> could become a good tool for lens calibration, if we add some Thomas> more general lens models to libpano. Those could easily be Thomas> invoked via new PToptimize options. that is the idea. The infrastructure for options is now in place in the branch. My next goal is to make an option to get rid of what I considered the most strange operation of PToptimizer: to overwrite the input file with the output file. The idea is that by default it will do as usual, but if specify it (using options) it will either output to the stdout or create an output file. So let us work on that branch until we are certain we are not breaking anything. --dmg Thomas> Regards, Tom -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Jim W. <jwa...@ph...> - 2011-02-09 19:43:20
|
On 2011-02-09 1:49 AM, D M German wrote: > I created a repository for the mercurial code: > > hg clone ssh://USE...@pa.../hgroot/panotools/panotools/libpano I tried a few different ways and can not get this to work. Anyone having luck? D:\source\panotools_psb>hg clone ssh://jim...@pa.../hgroot/panotools/panotools remote: abort: There is no Mercurial repository here (.hg not found)! abort: no suitable response from remote hg! D:\source\panotools_psb>hg clone http://panotools.hg.sourceforge.net:8000/hgroot/panotools/panotools real URL is http://sourceforge.net/ ** unknown exception encountered, please report by visiting ** http://mercurial.selenic.com/wiki/BugTracker ** Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] ** Mercurial Distributed SCM (version 1.7.5) ** Extensions loaded: fixfrozenexts Traceback (most recent call last): File "hg", line 36, in <module> File "mercurial\dispatch.pyo", line 16, in run File "mercurial\dispatch.pyo", line 36, in dispatch File "mercurial\dispatch.pyo", line 58, in _runcatch File "mercurial\dispatch.pyo", line 593, in _dispatch File "mercurial\dispatch.pyo", line 401, in runcommand File "mercurial\dispatch.pyo", line 644, in _runcommand File "mercurial\dispatch.pyo", line 598, in checkargs File "mercurial\dispatch.pyo", line 591, in <lambda> File "mercurial\util.pyo", line 426, in check File "mercurial\commands.pyo", line 736, in clone File "mercurial\hg.pyo", line 223, in clone File "mercurial\hg.pyo", line 96, in repository File "mercurial\httprepo.pyo", line 199, in instance File "mercurial\wireproto.pyo", line 75, in between File "mercurial\httprepo.pyo", line 137, in _call File "mercurial\httprepo.pyo", line 110, in _callstream File "rfc822.pyo", line 388, in __getitem__ KeyError: 'content-type' -- Jim Watters http://photocreations.ca |
From: Yuval L. <sf...@sf...> - 2011-02-09 21:51:10
|
On February 9, 2011 02:43:02 pm Jim Watters wrote: > On 2011-02-09 1:49 AM, D M German wrote: > > I created a repository for the mercurial code: > > > > hg clone > > ssh://USE...@pa.../hgroot/panotools/panotools/l > > ibpano > > I tried a few different ways and can not get this to work. > Anyone having luck? works here. You may want to check your list of known_hosts since the attack the hosts at SF have been restaged and have new fingerprints. Other, related subject: When comparing http://panotools.hg.sourceforge.net/hgweb/panotools http://hugin.hg.sourceforge.net/hgweb/hugin it seems that an extra directory level has been added. Why the complication? I recommend to move "libpano" and "others" up one level. Also "others" is not a meaningful name. What is in there? a simple rename with "mv" will give it a more meaningful name. Better do this before the new location gets widely publicized. Yuv |
From: Jim W. <jwa...@ph...> - 2011-02-10 05:12:31
|
On 2011-02-09 5:50 PM, Yuval Levy wrote: > On February 9, 2011 02:43:02 pm Jim Watters wrote: >> On 2011-02-09 1:49 AM, D M German wrote: >>> I created a repository for the mercurial code: >>> >>> hg clone >>> ssh://USE...@pa.../hgroot/panotools/panotools/l >>> ibpano >> I tried a few different ways and can not get this to work. >> Anyone having luck? > works here. You may want to check your list of known_hosts since the attack > the hosts at SF have been restaged and have new fingerprints. What do you mean by known_hosts? > http://panotools.hg.sourceforge.net/hgweb/panotools > http://hugin.hg.sourceforge.net/hgweb/hugin I was able to get the hugin code but not panotools using these links. I get the following error. 'content-type' real URL is http://sourceforge.net/ [command interrupted] Gets are anonymous so it should not have to do with accounts and passwords. -- Jim Watters http://photocreations.ca |
From: Bruno P. <br...@po...> - 2011-02-09 23:30:59
|
On Wed 09-Feb-2011 at 14:49 +0900, Daniel M. German wrote: > >I finally got access to the shell at sourceforge and created a >repository for the mercurial code: > >I created the repo last week, so any changes since have not been >reflected here. I'll take care of them. I pushed the two SVN commits from a couple of days ago into the new HG repo. We do need to fix it to have push messages go to the panotools-cvs list, I'm not sure how to do this. Are you going to merge Tomasz's test suite? It looks like it is all self-contained in tests/gsoc/ I'd like to do a 2.9.18 release candidate with this in it. >Please don't use the SVN repo any more We still have some stuff in SVN, is the plan to move everything over? -- Bruno |
From: Yuval L. <sf...@sf...> - 2011-02-10 02:04:04
|
On February 9, 2011 06:30:49 pm Bruno Postle wrote: > We do need to fix it to have push messages go to the panotools-cvs > list, I'm not sure how to do this. done for libpano. not sure what the purpose of the empty repository "other" is, but now you can just copy&paste .hg/hgrc from one repo to the other. not sure if this is going to be affected by the new SMTP password requirement (you probably received the email from SF, but in any case I will forward it to hugin-ptx). > We still have some stuff in SVN, is the plan to move everything > over? Is there any reason not to move everything over? Looking at http://panotools.svn.sourceforge.net/viewvc/panotools/trunk/ it seems to me destined to have one hg repo for each folder, maybe except CVSROOT? Yuv |
From: Yuval L. <sf...@sf...> - 2011-02-10 12:56:07
|
On February 10, 2011 12:12:13 am Jim Watters wrote: > On 2011-02-09 5:50 PM, Yuval Levy wrote: > > On February 9, 2011 02:43:02 pm Jim Watters wrote: > >> On 2011-02-09 1:49 AM, D M German wrote: > >>> I created a repository for the mercurial code: > >>> > >>> hg clone > >>> ssh://USE...@pa.../hgroot/panotools/panotools/ > >>> l ibpano > >> > >> I tried a few different ways and can not get this to work. > >> Anyone having luck? > > > > works here. You may want to check your list of known_hosts since the > > attack the hosts at SF have been restaged and have new fingerprints. > > What do you mean by known_hosts? I don't know where it is stored on Windows, probably in some registry settings. The SSH protocol (which I believe is integrated in TortoiseHg by way of a PuTTY copy) checks the fingerprint of a host before connecting. If the fingerprint behind that same IP address or domain name changes, this may be a sign of tampering and it refuses connection, asking you to investigate or, if you know for sure that the server's fingerprint has changed, override. In the case of SourceForge, the fingerprints have all changed after the recent attack. > > http://panotools.hg.sourceforge.net/hgweb/panotools > > http://hugin.hg.sourceforge.net/hgweb/hugin > > I was able to get the hugin code but not panotools using these links. actually these links were ment to browse and look at the repo structure, not really for getting the code. With panotools, you would have to add another /panotools because of the extra folder that has been interposed between the actual repositories and the filesystem root. @Daniel: is this extra folder by design? or may I move the libpano repo up one folder to the canonical location of repos at SourceForge as described in [0]? Quoted from that document: To create a new repository, you need to access the Shell service, then follow these steps: * Navigate to your repository o PROJECTUNIXNAME is the UNIX name of your project o P represents the first letter of that name, and PR the first two letters of the name. cd /home/scm_hg/P/PR/PROJECTUNIXNAME * Create a new directory with the name you want for the repository. * Execute hg init DIRNAME (where DIRNAME represents the name of the repository to be created). This will initialize a new repository at that directory. * edit .hg/hgrc in the repo * chmod -R g+w the whole repository (SF quirk) > I > get the following error. > 'content-type' > real URL is http://sourceforge.net/ > [command interrupted] that's because the URL is not right. > Gets are anonymous so it should not have to do with accounts and passwords. Indeed. I was trying to guide you to SSH operation, so that you can do both pulls and pushes. You do not really need the http protocol since you are a committer. Yuv [0] http://sourceforge.net/apps/trac/sourceforge/wiki/Mercurial |
From: Jim W. <jwa...@ph...> - 2011-02-10 14:45:46
|
Sorry for the missinformation before these are the actual links that I tried. The Hugin one worked and the panotools one did not. I want to eliminate SSH as a cause of the problem that is why I used http http://hugin.hg.sourceforge.net:8000/hgroot/hugin/hugin http://panotools.hg.sourceforge.net:8000/hgroot/panotools/panotools/libpano and if I run them on the command line with the -v for more info this is what I get. D:\source\panotoolspsb>hg clone http://panotools.hg.sourceforge.net:8000/hgroot/panotools/panotools/libpano -v real URL is http://sourceforge.net/ ** unknown exception encountered, please report by visiting ** http://mercurial.selenic.com/wiki/BugTracker ** Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] ** Mercurial Distributed SCM (version 1.7.5) ** Extensions loaded: fixfrozenexts Traceback (most recent call last): File "hg", line 36, in <module> File "mercurial\dispatch.pyo", line 16, in run File "mercurial\dispatch.pyo", line 36, in dispatch File "mercurial\dispatch.pyo", line 58, in _runcatch File "mercurial\dispatch.pyo", line 593, in _dispatch File "mercurial\dispatch.pyo", line 401, in runcommand File "mercurial\dispatch.pyo", line 644, in _runcommand File "mercurial\dispatch.pyo", line 598, in checkargs File "mercurial\dispatch.pyo", line 591, in <lambda> File "mercurial\util.pyo", line 426, in check File "mercurial\commands.pyo", line 736, in clone File "mercurial\hg.pyo", line 223, in clone File "mercurial\hg.pyo", line 96, in repository File "mercurial\httprepo.pyo", line 199, in instance File "mercurial\wireproto.pyo", line 75, in between File "mercurial\httprepo.pyo", line 137, in _call File "mercurial\httprepo.pyo", line 110, in _callstream File "rfc822.pyo", line 388, in __getitem__ KeyError: 'content-type' Searching the bug tracker on mercurial indicates that it is a servers problem, but they also have a bug and should not crash. And Hugin worked. D:\source\hugintest>hg clone http://hugin.hg.sourceforge.net:8000/hgroot/hugin/hugin/doc -v destination directory: doc requesting all changes adding changesets adding manifests adding file changes added 4951 changesets with 21354 changes to 5946 files (+13 heads) updating to branch default resolving manifests getting .hgignore getting .hgtags getting AUTHORS getting CMakeLists.txt getting CMakeModules/AppleRELEASEOptions.cmake getting CMakeModules/Find7Zip.cmake getting CMakeModules/FindBoostPython.cmake .... Except it got everything in the hugin and not just the doc sub folder! :( Maybe anonymous has not been enabled with the panotools hg repository? >> Gets are anonymous so it should not have to do with accounts and passwords. > Indeed. I was trying to guide you to SSH operation, so that you can do both > pulls and pushes. You do not really need the http protocol since you are a > committer. I tried again with SSH and it worked this time. This time I included the libpano at the end of the path the first time. Previously I attempted several times without libpano hopping to get all. Maybe I had too many failed attempts. New day and a reboot of the computer is maybe what it needed. -- Jim Watters http://photocreations.ca |
From: Bruno P. <br...@po...> - 2011-02-10 23:36:01
|
On Wed 09-Feb-2011 at 21:03 -0500, Yuval Levy wrote: > >Is there any reason not to move everything over? > >Looking at http://panotools.svn.sourceforge.net/viewvc/panotools/trunk/ it >seems to me destined to have one hg repo for each folder, maybe except >CVSROOT? Yes they are all projects that are alive or have some potential. There are also some things in /branches/ that need to be available for reference, they could stay in SVN. -- Bruno |
From: dmg <dm...@uv...> - 2011-02-10 23:42:51
|
There is no reason. I didn't want to step on anybody's toes. By the way, the "other" repository is the default one created by sourceforge. I didn't want to delete it before I knew things are working properly. It should be deleted once we know things are working. Has anybody tried to commit to it? --dmg On Fri, Feb 11, 2011 at 8:35 AM, Bruno Postle <br...@po...> wrote: > On Wed 09-Feb-2011 at 21:03 -0500, Yuval Levy wrote: >> >>Is there any reason not to move everything over? >> >>Looking at http://panotools.svn.sourceforge.net/viewvc/panotools/trunk/ it >>seems to me destined to have one hg repo for each folder, maybe except >>CVSROOT? > > Yes they are all projects that are alive or have some potential. > There are also some things in /branches/ that need to be available > for reference, they could stay in SVN. > > -- > Bruno > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > > -- --dmg --- Daniel M. German http://turingmachine.org |
From: Yuval L. <sf...@sf...> - 2011-02-11 12:41:56
|
On February 10, 2011 06:42:13 pm dmg wrote: > There is no reason. I didn't want to step on anybody's toes. OK, thanks for the clarification. I think we are all equally motivated not to step on anybody's toes :) Did you script your conversion to mercurial? did you convert also the other folders, or only the libpano folder? The only documentation I have left from moving Hugin is [0] and the two following articles. It would take me some time to start everything from scratch on the panotools SVN and I am short of time at the moment. Do you think you can take care of converting all the folders in trunk (maybe with the exception of CVSROOT?) into individual Mercurial repos? If not, I can do it, but I can't guarantee the time frame. > By the way, the "other" repository is the default one have you renamed it? when I moved Hugin, the default one was "hugin" and I would have expected the default one to be "panotools" in this case. Nobody has been committing anything to it. As of writing it is a blank, empty repo as created by `hg init` and the best solution for it is to log on to the SF shell and `rm -fr` it before anything is committed to it. Target layout are seven different repositories: - MPRemap - Panotools-Script - clens - gimp-plugin-ng - htdocs - libpano - ptfilter Unless there are objections / better ways to do things. Until recently I was under the impression that you only wanted to migrate the library, leaving everything else to continue in SVN. But if the people working on the "everything else" are comfortable moving to Hg, it makes sense IMO to move everything to Hg and reduce complexity. > On Fri, Feb 11, 2011 at 8:35 AM, Bruno Postle <br...@po...> wrote: > > On Wed 09-Feb-2011 at 21:03 -0500, Yuval Levy wrote: > >>Is there any reason not to move everything over? > >> > >>Looking at http://panotools.svn.sourceforge.net/viewvc/panotools/trunk/ > >>it seems to me destined to have one hg repo for each folder, maybe > >>except CVSROOT? > >> > > Yes they are all projects that are alive or have some potential. > > There are also some things in /branches/ that need to be available > > for reference, they could stay in SVN. Makes sense. Yuv [0] http://panospace.wordpress.com/2010/05/19/svn2hg_part1/ [1] http://panotools.svn.sourceforge.net/viewvc/panotools/trunk/ |
From: Jim W. <jwa...@ph...> - 2011-02-11 16:51:54
|
On 2011-02-11 8:41 AM, Yuval Levy wrote: > Target layout are seven different repositories: > - MPRemap > - Panotools-Script > - clens > - gimp-plugin-ng > - htdocs > - libpano > - ptfilter > > Unless there are objections / better ways to do things. > > Until recently I was under the impression that you only wanted to migrate the > library, leaving everything else to continue in SVN. But if the people > working on the "everything else" are comfortable moving to Hg, it makes sense > IMO to move everything to Hg and reduce complexity. I think all of these should be copied. SVN should be read only. In branches there may be a couple that should also be migrated. libpano_gsoc2010_regtests I don't know if the rest have anything of worth and that has not been merge into the main trunk. -- Jim Watters http://photocreations.ca |
From: Yuval L. <sf...@sf...> - 2011-02-11 13:19:51
|
On February 10, 2011 09:44:58 am Jim Watters wrote: > Sorry for the missinformation before my apology (I guess I am getting more 'Canadian' every day) for the confusion as well, and for not being very prompt in my replies (time is short at the moment). We'll get this sorted out. > The Hugin one worked and the panotools one did not. Can you try the panotools again with http://panotools.hg.sourceforge.net:8000/hgroot/panotools/libpano it is now exactly the same set up as Hugin, unless I missed something (e.g. permissioning). > I want to eliminate SSH as a cause of the problem Understand. From my experience, SSH is easier than HTTP. As part of my current day-job I implemented an Hg install; and while at it, alarmed by the SF brak-in problems, I also implemented an Hg "mirror" of Hugin on my own web server. Accessing my mirror with SSH works painless, out of the box. WWW access was a pain and I am still bumping into issues. The ultimate goal of the "mirror" is to set up a "federation" of mutually trusting repos pushing and pulling from each other to make the project completely independent of any central hosting, but it is very premature to discuss this and completely off topic. It's something like github functionality without the dependency on the hub. > Except it got everything in the hugin and not just the doc sub folder! :( That's "normal". You can't check out just a sub folder of a repository yet. I know development is moving in that direction, but is not there yet. Also, it is not as critical as in SVN. In SVN every single check in/out is a net operation. Bandwidth, latency, connection are critical. In Hg, once you have a clone of the *whole* repository, all check in/out operations are just local disk access. Only push/pull are bandwidth, latency, connection dependent. The Hugin repo is quite large, although by today's standards, at about 63MB, a drop in the ocean with respect to hard disk size. The initial cloning is the only operation that really suffers from this. > Maybe anonymous has not been enabled with the panotools hg repository? anonymous does not really need to be enabled. If you can see it in the web browser, it should work. > I tried again with SSH and it worked this time. good! as I stated, SSH is easier. But now you will have to change the URL since I have moved the location of the repo. Sorry for that. In a text editor, open .hg/hgrc and change [paths] default = ssh://US...@pa.../hgroot/panotools/panotools/libpano to read [paths] default = ssh://US...@pa.../hgroot/panotools/libpano Yuv |
From: Jim W. <jwa...@ph...> - 2011-02-11 15:37:17
|
On 2011-02-11 9:19 AM, Yuval Levy wrote: >> The Hugin one worked and the panotools one did not. > Can you try the panotools again with > > http://panotools.hg.sourceforge.net:8000/hgroot/panotools/libpano > > it is now exactly the same set up as Hugin, unless I missed something (e.g. > permissioning). Yes it works now. And I have updated my paths. -- Jim Watters http://photocreations.ca |