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
3) prerelease beta versions that are likely to be merged into a release
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.
On Fri, Jan 28, 2011 at 12:09 AM, D M German <dmg@...> 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
> - 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),
> - 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.
> Daniel M. German
> 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
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> PanoTools-devel mailing list