From: D M G. <dm...@uv...> - 2011-01-26 08:40:10
|
hi everybody, Probably many of you will agree that a move to a DVC is needed. This will help manage the new features that we are planning at the same time as integrating the testing framework that resulted from the previous GSoc. Today I spend a good amount of time reading about mercurial and git, and I decided that git is more adequate for the way that libpano is being developed. And since I know more about git than hg, I prefer it. I am currently in the process of migrating the history of libpano into git. would anybody object if I do the move (of only libpano, not the other modules). The bare repository will be hosted by sourceforge. --dmg -- -- 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-01-26 13:48:54
|
On Wed, Jan 26, 2011 at 3:40 AM, D M German <dm...@uv...> wrote: > > hi everybody, > > Probably many of you will agree that a move to a DVC is needed. This > will help manage the new features that we are planning at the same time > as integrating the testing framework that resulted from the previous GSoc. > > Today I spend a good amount of time reading about mercurial and git, and > I decided that git is more adequate for the way that libpano is being > developed. And since I know more about git than hg, I prefer it. > > I am currently in the process of migrating the history of libpano into > git. > > would anybody object if I do the move (of only libpano, not the other > modules). The bare repository will be hosted by sourceforge. > > --dmg > > I'm not a fan of progress for progress' sake; but if you think migrating to git would make maintaining libpano work better, so be it. Are you talking about both libpano12 and libpano13, or just the latter? This seems like good opportunity to formally drop support for the legacy panotools (I mean the closed source and Java based ones, and the PT plugins) if we haven't already done so. I think those modules could reasonably be frozen at the current libpano12 level (or indeed a much earlier one). That would make it a bit easier to introduce new features such as portable lens calibration, that are useful for panography but might break some of the original panotools. The current open source suite, which targets only panography, needs to be kept current with libpano13, IMO. So I wonder if it should not also migrate to a new DVC. Regards, Tom |
From: Yuval L. <sf...@sf...> - 2011-01-26 15:01:34
|
I am OK with either git or mercurial, just please no bazaar. That said, On January 26, 2011 08:48:47 am Thomas Sharpless wrote: > I'm not a fan of progress for progress' sake +1, and I don't have the impression that SVN has hit a ceiling (as it did with Hugin). > The current open source suite, which targets only panography, needs to be > kept current with libpano13, IMO. So I wonder if it should not also > migrate to a new DVC. If we are talking compatibility: beyond panotools, please consider that both Hugin and Enblend are on Mercurial and that Hugin depends on Libpano. A single tool, while not critical, would facilitate life for the many of us who are working on Hugin and depend on Libpano. I am not sure how Windows support for git is. Mercurial was chosen for Hugin because of better Windows support. This might have changed in the meantime. Whatever you do, I support. Please make sure that the information on the panotools wiki is updated, and inform people on the hugin-ptx mailing list. Yuv |
From: Thomas S. <tks...@gm...> - 2011-01-26 15:23:27
|
I think Yuv is right that libpano13 should more properly live in an hg repository than a git one. Indeed, it should be in the Hugin source tree. It is a big dependency of Hugin and of no other large project I know of. The open source commandline tools based on it belong there too. They are a valuable part of the Hugin distribution, and should be built automatically along with Hugin. As I said, I'd favor "pickling" libpano12 and all its apps in their present state and location (after, perhaps, some work on the build systems so that anyone who wanted to could reliably build them). -- Tom 2011/1/26 Yuval Levy <sf...@sf...> > I am OK with either git or mercurial, just please no bazaar. > > That said, > > On January 26, 2011 08:48:47 am Thomas Sharpless wrote: > > I'm not a fan of progress for progress' sake > > +1, and I don't have the impression that SVN has hit a ceiling (as it did > with > Hugin). > > > > The current open source suite, which targets only panography, needs to > be > > kept current with libpano13, IMO. So I wonder if it should not also > > migrate to a new DVC. > > If we are talking compatibility: beyond panotools, please consider that > both > Hugin and Enblend are on Mercurial and that Hugin depends on Libpano. A > single tool, while not critical, would facilitate life for the many of us > who > are working on Hugin and depend on Libpano. > > I am not sure how Windows support for git is. Mercurial was chosen for > Hugin > because of better Windows support. This might have changed in the > meantime. > > Whatever you do, I support. Please make sure that the information on the > panotools wiki is updated, and inform people on the hugin-ptx mailing list. > > Yuv > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better > price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > > |
From: Yuval L. <sf...@sf...> - 2011-01-29 10:24:03
|
On January 28, 2011 12:09:47 am D M German wrote: > here are some reasons I like git over mercurial (please keep in mind i > am not a hg expert, so I might be confusing/missing something). I really don't care which one it is between git and hg. DVCs are more or less interchangeable. I know of at least one dev on the Hugin team that used git for his personal repo while Hugin was still SVN; and interfacing between hg and git is even easier. I would prefer not to have to install all of them; but it is a weak preference and I can live with any of the envisioned tools. > - I like that there is a single end-node in git (the head) but I don't > like that hg allows multiple ones (heads) and one of them is the > tip (this might be an advantage of hg, but I am not > sure because I haven't used it). A hook can be configured to prevent multiple heads [0] > - I like that everything in git happens in one single directory, where > you move across branches with one command, and you can "stash" > changes. In mercurial, every branch is a subdirectory of the > repository. I am not sure I follow you here. With Hg, everything happens in one single directory as well. Within that directory, I can bring up any branch with hg up -C <YOUR_BRANCH> and I can copy any changeset from any other branch to that branch with hg export --git <REVISION_NUMBER> | hg import - note the --git flag which uses the git format for diff. I have not tried to move between Hg and git, but I would not be surprised if it was very easy and you and I could develop the same codebase in the two tools, pushing/pulling changes from each/other while you use git and I use Hg. > - Git has more traceability: I like how committer and author are both > recorded in git. In hg, committer info is lost. I can't really comment on this, I don't know Git well enough. Traceability is sure a weakness in hg, I can "spoof" the committer and author information all along the way. Then what is the point of differentiating committer and author if that difference is spoofable? > - Operations (important) my take on that is that functionality permeates across DVCS: enough users are smart and capable coders and will copy from each other: > - git-grep (which can search history), [1] > - git-bisect (binary search of the change that introduced a bug), hg bisect > - git-diff, which pinpoints the function where the change is > happening (I don't think hg does this). If it is "just" the diff format that is different, hg diff --git should do it. [2] > Other than because "hg is used by hugin", can anybody comment on why hg > rather than git? The reasons why I like Mercurial: * documentation * it is scripted and very easy to extend/customize/modify * if you have access to some basic webspace, you can do without central repo. > Now, libpano does not have many developers, so what I really want/need > is easier management of experimental (mostly personal) branches. In that case I would go back to the original argument (I think by Tom): why change for change sake? Gerry Patterson set up his own git repo to interface with Hugin's SVN back in the days when Hugin was still on SVN. Yuv [0] http://mercurial.selenic.com/wiki/TipsAndTricks#Prevent_a_push_that_would_create_multiple_heads [1] http://blog.axant.it/archives/283 [2] http://mercurial.selenic.com/wiki/GitExtendedDiffFormat |
From: D M G. <dm...@uv...> - 2011-01-31 04:03:36
|
Ok, we'll move to hg. --dmg -- 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-01-26 21:53:06
|
On 2011-01-26 11:23 AM, Thomas Sharpless wrote: > I think Yuv is right that libpano13 should more properly live in an hg > repository than a git one. I don't know of the advantages of git or mercurial over SVN. But being that the main use of Panotools is for Hugin if it is going to change, it sounds better to keep them the same as Hugin. > Indeed, it should be in the Hugin source tree. It is a big dependency of > Hugin and of no other large project I know of. The open source commandline > tools based on it belong there too. They are a valuable part of the Hugin > distribution, and should be built automatically along with Hugin. There is a better chance of others projects using Panotools if it is kept separate. > This seems like good opportunity to formally drop support for the legacy > panotools (I mean the closed source and Java based ones, and the PT plugins) > if we haven't already done so. I have been working on the PT plugins for Photoshop. The plugins are not closed source. Adobe has opened up the SDK required to build them. Nothing to sign and mail back anymore. I should have created a branch and have been checking my changes in for a while now. But I have been wanting to clean up the code... With my changes I don't know if the built in dialogs to preform adjustments and corrections still work on non Windows platforms. Plugins for Gimp were moved to a different folder. I have only been building and testing on Windows. Besides PTplugins and PTGui (using pano12.dll) I don't know of any other applications that show the dialogs. I don't think Hugin does. My next step in the plugins is to move to Qt for the UI. This will allow easily creating and building Windows and Mac versions. It would also be nice to incorporate the Gimp version back it the main Plugin code. This would mean the plugins would no longer need the code inside Panotools for displaying the dialogs. The dialogs would be much easier to change if they were separated. Sorry I have gotten a bit off topic. ... What I am trying to say is that Hugin is not the only use of Panotools, although it is the main user. -- Jim Watters http://photocreations.ca |
From: D M G. <dm...@uv...> - 2011-01-28 04:26:50
|
Jim Watters twisted the bytes to say: Jim> On 2011-01-26 11:23 AM, Thomas Sharpless wrote: >> I think Yuv is right that libpano13 should more properly live in an hg >> repository than a git one. Jim> I don't know of the advantages of git or mercurial over SVN. But being that the Jim> main use of Panotools is for Hugin if it is going to change, it sounds better to Jim> keep them the same as Hugin. >> Indeed, it should be in the Hugin source tree. It is a big dependency of >> Hugin and of no other large project I know of. The open source commandline >> tools based on it belong there too. They are a valuable part of the Hugin >> distribution, and should be built automatically along with Hugin. Jim> There is a better chance of others projects using Panotools if it is kept separate. >> This seems like good opportunity to formally drop support for the legacy >> panotools (I mean the closed source and Java based ones, and the PT plugins) >> if we haven't already done so. Jim> I have been working on the PT plugins for Photoshop. The plugins are not closed Jim> source. Adobe has opened up the SDK required to build them. Nothing to sign Jim> and mail back anymore. Jim> I should have created a branch and have been checking my changes Jim> in for a while now. But I have been wanting to clean up the Jim> code... This is also my problem. I have a lot of experimental code that I should upload, but handling branches is a pain. one of the things I don't like about SVN (and similarly of hg) is that every branch has to live in a different directory. I have many directories with libpano with experimental code that I have not committed because I don't want to pollute the repository. Jim> With my changes I don't know if the built in dialogs to preform Jim> adjustments and corrections still work on non Windows platforms. Jim> Plugins for Gimp were moved to a different folder. I have only Jim> been building and testing on Windows. Jim> Besides PTplugins and PTGui (using pano12.dll) I don't know of any Jim> other applications that show the dialogs. I don't think Hugin Jim> does. Libpano12 is consider only "maintenance" code. I haven't committed to it in a very long time. Jim> My next step in the plugins is to move to Qt for the UI. This will allow easily Jim> creating and building Windows and Mac versions. It would also be nice to Jim> incorporate the Gimp version back it the main Plugin code. I agree. Jim> This would mean the plugins would no longer need the code inside Panotools for Jim> displaying the dialogs. The dialogs would be much easier to change if they were Jim> separated. yes, each of these should be a different module, so that there is total independence in the way each module is created/managed. Jim> Sorry I have gotten a bit off topic. Jim> ... What I am trying to say is that Hugin is not the only use of Panotools, Jim> although it is the main user. Jim> -- Jim> Jim Watters Jim> http://photocreations.ca Jim> ------------------------------------------------------------------------------ Jim> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Jim> Finally, a world-class log management solution at an even better price-free! Jim> Download using promo code Free_Logger_4_Dev2Dev. Offer expires Jim> February 28th, so secure your free ArcSight Logger TODAY! Jim> http://p.sf.net/sfu/arcsight-sfd2d Jim> _______________________________________________ Jim> PanoTools-devel mailing list Jim> Pan...@li... Jim> https://lists.sourceforge.net/lists/listinfo/panotools-devel -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Yuval L. <sf...@sf...> - 2011-01-27 13:56:37
|
On January 26, 2011 12:07:31 pm Jim Watters wrote: > On 2011-01-26 11:23 AM, Thomas Sharpless wrote: > > Indeed, it should be in the Hugin source tree. It is a big dependency of > > Hugin and of no other large project I know of. The open source > > commandline tools based on it belong there too. They are a valuable > > part of the Hugin distribution, and should be built automatically along > > with Hugin. > > There is a better chance of others projects using Panotools if it is kept > separate. agree with Jim - same tool yes. same repository not. Hugin's SVN repo was bloated with many things because SourceForge did allow only one SVN per project. Since they allow multiple Hg per project, I have split out the code into multiple repos: http://hugin.hg.sourceforge.net/hgweb/hugin/ Yuv |
From: D M G. <dm...@uv...> - 2011-01-28 04:23:41
|
Yuval Levy twisted the bytes to say: Yuval> On January 26, 2011 12:07:31 pm Jim Watters wrote: >> On 2011-01-26 11:23 AM, Thomas Sharpless wrote: >> > Indeed, it should be in the Hugin source tree. It is a big dependency of >> > Hugin and of no other large project I know of. The open source >> > commandline tools based on it belong there too. They are a valuable >> > part of the Hugin distribution, and should be built automatically along >> > with Hugin. >> >> There is a better chance of others projects using Panotools if it is kept >> separate. Yuval> agree with Jim - same tool yes. same repository not. Hugin's SVN repo was Yuval> bloated with many things because SourceForge did allow only one SVN per Yuval> project. Since they allow multiple Hg per project, I have split out the code Yuval> into multiple repos: I also think going into the same "module" is a bad idea. But I would not oppose libpano to be inside the hugin repository. One of the problems of DVS is that they do not allow you to extract a portion of the repository only (say a subdirectory of hugin), instead you need to download the entire one. For example, imagine you only want nona. You need to download the entire hugin tree (and configure it) to be able to build nona. I personally think that libpano should be split into two: the tools and the library. Hugin, for example, does not need/use the tools. But the tools are useful to test the library, so that is why they have been living together. One advantage of git, is how easy it is to maintain "forks". So the tree of hugin might contain a "fork" of libpano that gets updated every time a new release is created. They can also send us patches back to libpano, and maintain changes that might be tooo hugin specific. I presume that it would be interesting to test if one can maintain a source tree with two different repositories (one git and one svn). For example, I used to do this with SVN and CVS: the external repository was in CVS, and my internal one in SVN. That way I had local commits, and I could commit locally or remotely. If mercurial can play with git, then it could be very useful: the libpano people (like me) maintain in git, and the hugin people branch a copy in their repository (under mercurial) but communicate back to us using git. Sounds complicated, but it is very effective. --dmg Yuval> http://hugin.hg.sourceforge.net/hgweb/hugin/ Yuval> Yuv Yuval> ------------------------------------------------------------------------------ Yuval> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Yuval> Finally, a world-class log management solution at an even better price-free! Yuval> Download using promo code Free_Logger_4_Dev2Dev. Offer expires Yuval> February 28th, so secure your free ArcSight Logger TODAY! Yuval> http://p.sf.net/sfu/arcsight-sfd2d_______________________________________________ Yuval> PanoTools-devel mailing list Yuval> Pan...@li... Yuval> https://lists.sourceforge.net/lists/listinfo/panotools-devel -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Yuval L. <sf...@sf...> - 2011-01-29 10:45:05
|
On January 27, 2011 11:23:30 pm D M German wrote: > I also think going into the same "module" is a bad idea. But I would not > oppose libpano to be inside the hugin repository. > > One of the problems of DVS is that they do not allow you to extract a > portion of the repository only and that problem is the reason why I would oppose libpano to be inside the hugin repo. It would make life miserable for the users of libpano that do not use hugin. > For example, imagine you only want nona. You need to download the entire > hugin tree (and configure it) to be able to build nona. yes, that's the current state of affair. > I personally think that libpano should be split into two: the tools and > the library. Hugin, for example, does not need/use the tools. But the > tools are useful to test the library, so that is why they have been > living together. would you split them in two at the DVCS level? In Debian/Ubuntu they are already split into two different binary packages so that as a user I don't have to install the tools if I don't need them. as a builder, I would want to test the library before unleashing it on the users, so having the tests in the same repo is a good thing. > One advantage of git, is how easy it is to maintain "forks". So the tree > of hugin might contain a "fork" of libpano that gets updated every time > a new release is created. They can also send us patches back to libpano, > and maintain changes that might be tooo hugin specific. can you elaborate on this? how do you maintain such a "fork"? is it the same as vendor branches in SVN [0]? > I presume that it would be interesting to test if one can maintain a > source tree with two different repositories (one git and one svn). Should be possible. I think one of them would have to be declared "master", though. > If mercurial can play with git, then it could be very useful: the > libpano people (like me) maintain in git, and the hugin people branch a > copy in their repository (under mercurial) but communicate back to us > using git. Sounds complicated, but it is very effective. I question the need to maintain a libpano branch inside Hugin. Even if it is very effective, what advantage does it bring over two separate repos? Yuv [0] http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html |
From: Thomas S. <tks...@gm...> - 2011-01-27 16:30:31
|
Yuv, Does hugin have an official libpano13 source, or is it builder's choice? If there is an official source: 1) is it the one in the panotools repository, or the one in hugin's libpanorama repository? 2) wouldn't it be a good idea to combine those into one? Regards, Tom 2011/1/27 Yuval Levy <sf...@sf...> > On January 26, 2011 12:07:31 pm Jim Watters wrote: > > On 2011-01-26 11:23 AM, Thomas Sharpless wrote: > > > Indeed, it should be in the Hugin source tree. It is a big dependency > of > > > Hugin and of no other large project I know of. The open source > > > commandline tools based on it belong there too. They are a valuable > > > part of the Hugin distribution, and should be built automatically along > > > with Hugin. > > > > There is a better chance of others projects using Panotools if it is kept > > separate. > > agree with Jim - same tool yes. same repository not. Hugin's SVN repo was > bloated with many things because SourceForge did allow only one SVN per > project. Since they allow multiple Hg per project, I have split out the > code > into multiple repos: > > http://hugin.hg.sourceforge.net/hgweb/hugin/ > > Yuv > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better > price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > > |
From: Bruno P. <br...@po...> - 2011-01-27 23:08:43
|
On Thu 27-Jan-2011 at 11:30 -0500, Tom Sharpless wrote: > >Does hugin have an official libpano13 source, or is it builder's choice? Yes stable Hugin releases usually require particular tarball releases of libpano13. The current Hugin development branch needs a libpano13 snapshot. There was a copy of libpano13 in the Windows Hugin SDK, but this is/was just for convenience >If there is an official source: >1) is it the one in the panotools repository, or the one in hugin's >libpanorama repository? >2) wouldn't it be a good idea to combine those into one? libpanorama is something else altogether. The definitive libpano13 is the SVN repository in the panotools sourceforge project: https://panotools.svn.sourceforge.net/svnroot/panotools/trunk/libpano/ -- Bruno |
From: D M G. <dm...@uv...> - 2011-01-28 05:09:57
|
Yuval> If we are talking compatibility: beyond panotools, please Yuval> consider that both Hugin and Enblend are on Mercurial and that Yuval> Hugin depends on Libpano. A single tool, while not critical, Yuval> would facilitate life for the many of us who are working on Yuval> Hugin and depend on Libpano. here are some reasons I like git over mercurial (please keep in mind i am not a hg expert, so I might be confusing/missing something). - Model based (somehow important, but not critical) - I like that there is a single end-node in git (the head) but I don't like that hg allows multiple ones (heads) and one of them is the tip (this might be an advantage of hg, but I am not sure because I haven't used it). - I like that everything in git happens in one single directory, where you move across branches with one command, and you can "stash" changes. In mercurial, every branch is a subdirectory of the repository. - Git has more traceability: I like how committer and author are both recorded in git. In hg, committer info is lost. - Operations (important) - In git there are three commands that are just great: - git-grep (which can search history), - git-bisect (binary search of the change that introduced a bug), and - git-diff, which pinpoints the function where the change is happening (I don't think hg does this). Other than because "hg is used by hugin", can anybody comment on why hg rather than git? Now, libpano does not have many developers, so what I really want/need is easier management of experimental (mostly personal) branches. We have code I have started that is floating in my computer: the linear mode for libpano Chris started, a half-done new parser, the recovery of the morphing feature in libpano. --dmg -- -- 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-01-28 16:32:14
|
Hi all We need to separate matters of personal preference about source management style, from issues that are important to present and future users of libpano. All of us could do a better job of maintaining and extending libpano, even if it stays in SVN . It seems to me the important source branches are: 1) a well tested release, used to build Hugin releases. 2) release versions of the open-source commandline tools, that use the release library. 3) prerelease beta versions that are likely to be merged into a release sometime soon. 4) branches that support other apps and experimental / personal uses. Even though Hugin itself may not strictly depend on them, I think the command line tools are an indispensable part of the Hugin releases, and should be given full support as such. I agree that it definitely should be easier to build just one app and a (possibly custom) version of the library to support it. But that is more a matter of build tools than source code control -- in other words, we have to make that happen by our own efforts. With an IDE having good project management/configuration capabilities, one can mix-and-match sources from different directories without too much trouble. On Windows, MSVC is perfectly satisfactory. I also like Qt Creator, which is portable. It is not a 'full featured' front end to the Gnu tools, but is not limited to Qt builds, does a decent job of project management, and generates usable makefiles; the current version builds outside the source tree, which I consider essential. My 2nd choice for portable build control would be QMake, mainly for its ability to put builds in separate directories from the source tree; however it offers little help for project/configuration management. Autoconf/automake/gmake is even less flexible and more obscure, and really is limited to ***x platforms. It is beyond my comprehension why anyone still wants to use that, when there are good IDEs for those platforms (now we are back to personal preferences :-). There are some serious issues with keeping project files in a shared source repository. By nature, those files contain local configuration information, that every developer will likely need to change. I always wind up having to exclude most of the MSVC projects when committing a libpano change, because they have been 'touched' if not actually fiddled, in ways that would not be useful to other developers. If one of the proposed SCCSs has specific features to deal with project management problems, then that is the one I would vote for. If not, let's stick with SVN and get on with the job. Best, Tom On Fri, Jan 28, 2011 at 12:09 AM, D M German <dm...@uv...> wrote: > > > Yuval> If we are talking compatibility: beyond panotools, please > Yuval> consider that both Hugin and Enblend are on Mercurial and that > Yuval> Hugin depends on Libpano. A single tool, while not critical, > Yuval> would facilitate life for the many of us who are working on > Yuval> Hugin and depend on Libpano. > > here are some reasons I like git over mercurial (please keep in mind i > am not a hg expert, so I might be confusing/missing something). > > - Model based (somehow important, but not critical) > > - I like that there is a single end-node in git (the head) but I don't > like that hg allows multiple ones (heads) and one of them is the > tip (this might be an advantage of hg, but I am not > sure because I haven't used it). > > - I like that everything in git happens in one single directory, where > you move across branches with one command, and you can "stash" > changes. In mercurial, every branch is a subdirectory of the > repository. > > - Git has more traceability: I like how committer and author are both > recorded in git. In hg, committer info is lost. > > - Operations (important) > > - In git there are three commands that are just great: > > - git-grep (which can search history), > > - git-bisect (binary search of the change that introduced a bug), > and > > - git-diff, which pinpoints the function where the change is > happening (I don't think hg does this). > > > Other than because "hg is used by hugin", can anybody comment on why hg > rather than git? > > Now, libpano does not have many developers, so what I really want/need > is easier management of experimental (mostly personal) > branches. We have code I have started that is floating in my computer: > the linear mode for libpano Chris started, a half-done new parser, the > recovery of the morphing feature in libpano. > > --dmg > > > -- > -- > Daniel M. German > http://turingmachine.org/ > http://silvernegative.com/ > dmg (at) uvic (dot) ca > replace (at) with @ and (dot) with . > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better > price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > |
From: Yuval L. <sf...@sf...> - 2011-01-29 10:31:10
|
Hi Tom, On January 28, 2011 11:32:06 am Thomas Sharpless wrote: > Even though Hugin itself may not strictly depend on them, I think the > command line tools are an indispensable part of the Hugin releases, and > should be given full support as such. The panotools CLI tools are surely valuable for the serious panorama photographer, but they are not part of the Hugin releases: yuv@koolblu:~$ apt-cache search panotools libpano12-0 - panorama tools library libpano13-1 - panorama tools library libpano13-bin - panorama tools utilities enfuse - image exposure blending tool yuv@koolblu:~$ apt-cache search hugin autopano-sift-c - Automatically create control points for panorama image enfuse - image exposure blending tool hugin-data - panorama photo stitcher - common data files hugin - panorama photo stitcher - GUI tools hugin-tools - panorama photo stitcher - commandline tools Yuv |