[hugin-ptx] Re: Hugin Mercurial Repo - Please Test and Help

[Tduell]

Hullo Bruno,

On May 18, 9:17 pm, Bruno Postle  wrote:
[snip]
> What does `make package_source` generate? I can't test from here, this
> needs to create tarballs with stable predictable names (i.e.
> hugin-2010.1.0.tar.gz).

I have just tested this...in case the answer hasn't already been
given.
I updated to hg version number (that's probably not what one is
supposed to call this abomination, but you know what I mean)
a25f0ed5a87b , and 'make package_source' generates
hugin-2010.1.0.tar.gz, and .bz2, which archive a dir named
hugin-2010.1.0.
So package building should be OK.

Cheers,
Terry

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Hugin Mercurial Repo - Please Test and Help

[Harry van der Wolf]

Hi Yuv,


2010/5/18 Yuv 

>
> may I suggest to put KImageFuser with it's cousin ImageFuser in the
> same project repo? it can also be the Hugin project repo since we can
> have unlimited Hg repos.  Keeping the two of them together will
> enhance the probability that somebody will contribute to both.
>
> To create a new repository, you need to access the SourceForge 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: `mkdir REPO`
>* Execute `hg init REPO` This will initialize a new repository at
> that directory so you can start pushing to it with `hg push
> ssh://u...@hugin.hg.sourceforge.net/hgroot/hugin/REPO`
>* edit .hg/hgrc in the repo. easier is to start with a copy of the
> one for hugin and adapt it: `cp ../hugin/.hg/hgrc .hg/`
>
> Yuv
>
>
Never thought of this possibility. I will try. Thanks for the suggestion.

Harry

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Hugin Mercurial Repo - Please Test and Help

[Harry van der Wolf]

2010/5/18 Yuval Levy 

>
> Not a very reliable indicator.
>
> I would rather have something like:
>
> Hugin 2010.1.0.4033:a0de66c7eb13 built by Harry van der Wolf
>
>
agreed. That was my first stamp. The splash screen is too small to have this
long string. I ended up with "er Wolf" (or so) missing from the splash
screen.


> and even better something like
>
> Hugin ..-hg
> built
> by 
>
> with  = rev nr + SHA1ID (4033:a0de66c7eb13) and with 
> uniquely identifying the repository used.  I first thought of using a
> shortcut
> based on the owner / committer name, but that's a bad idea.  One person
> could
> have multiple repos on their hard drive.  Will have to research into more
> depth what Hg has to offer in this arena.  I don't have time until the
> weekend.
>
> Yuv
>
>
As such I agree. But in that case we do need to take a look at the string
length, or more likely, the string position. Otherwise it won't fit.

Harry

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] Re: Hugin Mercurial Repo - Please Test and Help

[T. Modes]

Hi all,

> Put in the Hg rev-nr in the fourth element instead of the SVN rev-nr
> and it will work well for all packages generated from the same repo.
> If the repo is a fresh clone of the SF central repo, the likelihood is
> very high that .1234 will stay .1234 across different packagers -
> important for distribution / package managing software.  On the other
> hand, if you've played with the repo (e.g. you're a developer), then
> your .1234 will be different than mine .2345 - not a problem if these
> packages are only part of the dev process and not distributed.

I don't agree. That will create more confusion for developer. When
there is a bug report I have to know from which version it is
reported. When each builder uses her own numbering sheme it is not
helpful, because I as a developer don't know from which point the bug
report comes (or if it is fixed in an following revision). A possible
solution would be that the builder have to provide in this case a
mapping of there repo number to the changeset so that I can check in
my repo (with other rev number) if this bug is still appliable or if
it is fixed by an already done bug fixing. But this is complicated.
I'm for using the changeset sha1 number as Harry already done. With a
small modification it should be possible to copy the version string
from the about screen.

Thomas

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Hugin Mercurial Repo - Please Test and Help

[Yuval Levy]

On May 18, 2010 10:38:10 am Harry van der Wolf wrote:
> My builds (or those from Skip Gaede or who else might build via XCode)
> mentioned the following in the splash screen:
> 
> Hugin ..-svn built by
> 
> so automatically resolved (by some scripting that is):
> Hugin 2010.1.0-svn5156 built by Harry van der Wolf
> 
> Since yesterday they mention:
> 
> Hugin 2010.1.0.a0de66c7eb13 built by Harry van der Wolf
> 
> Due to this mail exchange I now see that I use the wrong version stamp. I
> will change that to:
>  Hugin 2010.1.0.4033 built by Harry van der Wolf

don't (yet). let's first analyze the situation and get a better long term 
solution than a quick fix.

 
> (from parent: 4033:a0de66c7eb13 tip)
> 
> Remains the fact that we now go from svn number 5156 (my last bundle) to
> e.g. hg version 4033 or so in my new build (not yet there). I need to
> explain that on my website and remove all older builds to prevent confusion
> due to version numbers.

indeed 4033 < 5156 yields short term confusion.

2010.2.0.4033 > 2010.1.0.5156 and the confusion is (almost) cleared.

the built by  I introduced to the CMake build to distinguish 
Windows (and obviously Mac) builds - not every builder produces the same 
quality of builds, and good builder take pride in their builds and put their 
names there.  It is a plain text field entered at build time by the builder.  
Not a very reliable indicator.

I would rather have something like: 

Hugin 2010.1.0.4033:a0de66c7eb13 built by Harry van der Wolf

and even better something like 

Hugin ..-hg built 
by 

with  = rev nr + SHA1ID (4033:a0de66c7eb13) and with  
uniquely identifying the repository used.  I first thought of using a shortcut 
based on the owner / committer name, but that's a bad idea.  One person could 
have multiple repos on their hard drive.  Will have to research into more 
depth what Hg has to offer in this arena.  I don't have time until the 
weekend.

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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Hugin Mercurial Repo - Please Test and Help

[Harry van der Wolf]

2010/5/18 Yuv 

>  For platforms without package manager (e.g. Windows
> and OSX) I'd be tempted to use the changeset ID to name the installer
> - however it is not very user friendly to ask them to report an eight
> digits hex number.  An alternative would be builder & rev-r (e.g.
> Hugin-2010.1.0.4033-Harry) with builder being a proxy for the repo
> from which it was built.  Maybe there is a possibility to tap into the
> [ui] username variable inside .hgrc and make a shortened string out of
> it.  The first two digits of each word excluding the email address, so
> in my case it would become Hugin-2010.1.0.YuLe-4033 and in your case
> it would become Hugin-2010.1.0.KoBe-4033.  It is easier to explain a
> package manager warning with "you used a package from another builder"
> than with "mercurial internals and our less than perfect build have
> given it an out of sequence number".
>
> Yuv
>
>
>

My builds (or those from Skip Gaede or who else might build via XCode)
mentioned the following in the splash screen:

Hugin ..-svn built by

so automatically resolved (by some scripting that is):
Hugin 2010.1.0-svn5156 built by Harry van der Wolf

Since yesterday they mention:

Hugin 2010.1.0.a0de66c7eb13 built by Harry van der Wolf

Due to this mail exchange I now see that I use the wrong version stamp. I
will change that to:
 Hugin 2010.1.0.4033 built by Harry van der Wolf

(from parent: 4033:a0de66c7eb13 tip)

Remains the fact that we now go from svn number 5156 (my last bundle) to
e.g. hg version 4033 or so in my new build (not yet there). I need to
explain that on my website and remove all older builds to prevent confusion
due to version numbers.


Harry

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] Re: Hugin Mercurial Repo - Please Test and Help

[Yuv]

On May 18, 6:50 am, Kornel Benko  wrote:
> Am Dienstag 18 Mai 2010 schrieb Bruno Postle:
>
> > On 18 May 2010 09:42, Kornel Benko
>
> > > at least in this CMakeLists.txt the value of V_PATCH was hardcoded to
> > > "0".
>
> > > Changing it to the revision gives me what I wanted.
>
> > Please don't change the name of the tarball (or the folder inside it),
> > this will be a pain for packaging, and will have to be switched back
> > every time we do a  formal source release.
>
> I don't understand. If we append the revision, then the package name is 
> automatically changed too.

Yes, but it's the same as we did before with SVN.

I realize only now that you were talking of the third or patch number
in the complete version string, and not of the fourth.  The policy
with version number is that there are four dot separated elements to
it:
- major: the year of the release
- minor: a sequential number of release within the year, odd being a
development snapshot and even being a public release to production
- patch: incremented in case we must re-release the package (e.g.
security vulnerability, or if there have been enough post-release
improvements such as translations to warrant a re-release)
- revision numer: this is where the SVN revision number would come
in.  Meaningless but not disturbing for public releases to production,
helpful for feedback / bug reporting on development snapshots.

Put in the Hg rev-nr in the fourth element instead of the SVN rev-nr
and it will work well for all packages generated from the same repo.
If the repo is a fresh clone of the SF central repo, the likelihood is
very high that .1234 will stay .1234 across different packagers -
important for distribution / package managing software.  On the other
hand, if you've played with the repo (e.g. you're a developer), then
your .1234 will be different than mine .2345 - not a problem if these
packages are only part of the dev process and not distributed.  It
would generate confusion to distribute them to the general public (the
package manager may complain about a smaller version number / older
version when this is not the case), so particular care must be taken
when preparing tarballs for distribution.  An (unfortunately manual)
line of defense against such confusion is to use the changeset ID in
the "about dialog" and similar strategic places from where it can be
reported by the user.  The changeset ID is consistent across repos but
unfortunately it is not incremental so does not work nicely with
package managers.  For platforms without package manager (e.g. Windows
and OSX) I'd be tempted to use the changeset ID to name the installer
- however it is not very user friendly to ask them to report an eight
digits hex number.  An alternative would be builder & rev-r (e.g.
Hugin-2010.1.0.4033-Harry) with builder being a proxy for the repo
from which it was built.  Maybe there is a possibility to tap into the
[ui] username variable inside .hgrc and make a shortened string out of
it.  The first two digits of each word excluding the email address, so
in my case it would become Hugin-2010.1.0.YuLe-4033 and in your case
it would become Hugin-2010.1.0.KoBe-4033.  It is easier to explain a
package manager warning with "you used a package from another builder"
than with "mercurial internals and our less than perfect build have
given it an out of sequence number".

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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Windows 64-bit Build

[Nicolas Pelletier]

This explains the out of memory I got when I tried to ramp up enblend to 6
gig of ram.

To answer to Dex, I second that enblend is a bottleneck on my side as it is
IO bound here... but I did crash up nona for out of memory when remapping an
equirectangular to a very large stereographic output. so this part is not
lost.

The few test I did with the 64 bit version do work. I'll run my command line
process to test... but It may not be in the near future... life is getting
int the way.

Thanks for th x64 version.

nick

On Tue, May 18, 2010 at 7:20 AM, Tom Glastonbury wrote:

> Note that enblend/enfuse version 4.0 is what you'll get from my Windows
> 64-bit hugin builds. As you rightly say, it's not the 64-bit version - I'll
> work on that. As for your question - from reading some comments elsewhere,
> it looks like enblend/enfuse use some hand-crafted SSE code, and will use
> the 64-bit versions for 64-bit builds (note this is a somewhat speculative
> comment). I'd imagine that this could make a meaningful difference to
> performance. Anyhow, I'll get the 64-bit version going shortly then you can
> compare them side-by-side.
>
> Tom
>
>
> On 18/05/2010 10:27 AM, dex Otaku wrote:
>
>> Hey all,
>>
>> This may seem like a naīve non-developer question, but how much
>>
>> utility is gained with Hugin being 64-bit when enblend/enfuse isn't?
>>
>> The only problems I run into with Hugin currently are caused by
>> enblend running out of memory when trying to use --fine-mask [because
>> without it, banding or black lines sometimes occur].
>>
>>
>>
>
> --
> 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 hugin-ptx@googlegroups.com
> To unsubscribe from this group, send email to
> hugin-ptx+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] Re: Hugin Mercurial Repo - Please Test and Help

[Yuv]

Hoi Harry

On May 18, 3:45 am, Harry van der Wolf  wrote:
> > * KImageFuser
>
> >  - I did not do anything. Since Harry has been on Mercurial for it
> > for more than two months, I assume it already lives on Hg somewhere
> > else?
>
> No, it's not. I mentioned that ImageFuser is on Mercurial for 2 months.
> KImageFuser is it's Kommander KDE linux (little) brother that started when I
> had no macbook anymore.
> It is still on SVN. However, I have a local svn2hg repository on my server
> and I work with hg on my "local" repositories and then with svn to the
> central repository. As I hardly touch linux anymore I want to do some final
> functionality build-in and than it's done for me.
> It is no problem for me though to convert it myself to mercurial. I just
> make it a SourceForge new mercurial repo.

sorry for the *K*onfusion :-)

may I suggest to put KImageFuser with it's cousin ImageFuser in the
same project repo? it can also be the Hugin project repo since we can
have unlimited Hg repos.  Keeping the two of them together will
enhance the probability that somebody will contribute to both.

To create a new repository, you need to access the SourceForge 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: `mkdir REPO`
* Execute `hg init REPO` This will initialize a new repository at
that directory so you can start pushing to it with `hg push
ssh://u...@hugin.hg.sourceforge.net/hgroot/hugin/REPO`
* edit .hg/hgrc in the repo. easier is to start with a copy of the
one for hugin and adapt it: `cp ../hugin/.hg/hgrc .hg/`

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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Windows 64-bit Build

[Tom Glastonbury]

Note that enblend/enfuse version 4.0 is what you'll get from my Windows 
64-bit hugin builds. As you rightly say, it's not the 64-bit version - 
I'll work on that. As for your question - from reading some comments 
elsewhere, it looks like enblend/enfuse use some hand-crafted SSE code, 
and will use the 64-bit versions for 64-bit builds (note this is a 
somewhat speculative comment). I'd imagine that this could make a 
meaningful difference to performance. Anyhow, I'll get the 64-bit 
version going shortly then you can compare them side-by-side.


Tom

On 18/05/2010 10:27 AM, dex Otaku wrote:

Hey all,

This may seem like a naīve non-developer question, but how much
utility is gained with Hugin being 64-bit when enblend/enfuse isn't?

The only problems I run into with Hugin currently are caused by
enblend running out of memory when trying to use --fine-mask [because
without it, banding or black lines sometimes occur].

   


--
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Hugin Mercurial Repo - Please Test and Help

[Bruno Postle]

On 18 May 2010 10:50, Kornel Benko  wrote:

> For debian packaging on ubuntu I got now
>hugin-2010.1.0.4033-Linux.deb

This is fine, but note that 2010.2.0.1234 > 2010.2.0 so users of these
deb packages will have trouble upgrading to the final 'stable' release
when it appears in ubuntu if that is what they want to do.

What does `make package_source` generate? I can't test from here, this
needs to create tarballs with stable predictable names (i.e.
hugin-2010.1.0.tar.gz).

-- 
Bruno

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Hugin Mercurial Repo - Please Test and Help

[Kornel Benko]

Am Dienstag 18 Mai 2010 schrieb Bruno Postle:
> On 18 May 2010 09:42, Kornel Benko
> 
> > at least in this CMakeLists.txt the value of V_PATCH was hardcoded to
> > "0".
> > 
> > Changing it to the revision gives me what I wanted.
> 
> Please don't change the name of the tarball (or the folder inside it),
> this will be a pain for packaging, and will have to be switched back
> every time we do a  formal source release.
>

I don't understand. If we append the revision, then the package name is 
automatically changed too.

> Previously the SVN revision number was appended to the Hugin version
> in the About dialog i.e. 2010.1.0.1234 this works quite well (even for
> releases) and we can do something similar with HG.

In the appended patch I tried to set the hugin version to 2010.1.0.4033 .
(This patch works with german environment too)

For debian packaging on ubuntu I got now
hugin-2010.1.0.4033-Linux.deb
and after installing
# dpkg -l | grep hugin
ii  hugin   2010.1.0.4033   
   hugin built using CMake
so it seams ok for ubuntu. Don't know, how it behaves with rpm.

Kornel

-- 
Kornel Benko
kornel.be...@berlin.de
diff -r a0de66c7eb13 CMakeLists.txt
--- a/CMakeLists.txt	Tue May 18 10:20:30 2010 +0200
+++ b/CMakeLists.txt	Tue May 18 12:42:12 2010 +0200
@@ -28,7 +28,7 @@
   IF(NOT ${_hg} MATCHES "-NOTFOUND")
 EXECUTE_PROCESS(COMMAND ${_hg} summary WORKING_DIRECTORY "${PROJECT_SOURCE_DIR}" OUTPUT_VARIABLE _release OUTPUT_STRIP_TRAILING_WHITESPACE)
 foreach(_v_l ${_release})
-  if(_v_l MATCHES "^parent: *[^0-9]*\([0-9]+\):\([a-z0-9]+\)")
+  if(_v_l MATCHES "^.*: *[^0-9]*\([0-9]+\):\([a-z0-9]+\)")
 set(CPACK_PACKAGE_VERSION_PATCH ${CMAKE_MATCH_1})
 set(HUGIN_WC_REVISION ${CMAKE_MATCH_2})
   endif()
@@ -431,7 +431,7 @@
 
 SET(CPACK_PACKAGE_VERSION_MAJOR "${V_MAJOR}")
 SET(CPACK_PACKAGE_VERSION_MINOR "${V_MINOR}")
-SET(CPACK_PACKAGE_VERSION_PATCH "${V_PATCH}")
+SET(CPACK_PACKAGE_VERSION_PATCH "${V_PATCH}.${CPACK_PACKAGE_VERSION_PATCH}")
 SET(CPACK_PACKAGE_INSTALL_DIRECTORY "CMake ${V_MAJOR}.${V_MINOR}")
 SET(CPACK_SOURCE_PACKAGE_FILE_NAME "hugin-${V_MAJOR}.${V_MINOR}.${V_PATCH}")
 SET(CPACK_SOURCE_GENERATOR "TGZ;TBZ2")


signature.asc
Description: This is a digitally signed message part.

Re: [hugin-ptx] Re: Hugin Mercurial Repo - Please Test and Help

[Bruno Postle]

On 18 May 2010 09:42, Kornel Benko
> at least in this CMakeLists.txt the value of V_PATCH was hardcoded to "0".
>
> Changing it to the revision gives me what I wanted.

Please don't change the name of the tarball (or the folder inside it),
this will be a pain for packaging, and will have to be switched back
every time we do a  formal source release.

Previously the SVN revision number was appended to the Hugin version
in the About dialog i.e. 2010.1.0.1234 this works quite well (even for
releases) and we can do something similar with HG.

-- 
Bruno

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Hugin Mercurial Repo - Please Test and Help

[Kornel Benko]

Am Dienstag 18 Mai 2010 schrieb Yuv:
> Hallo Kornel,
> 
> On May 17, 10:30 am, Kornel Benko  wrote:
> > Am Montag 17 Mai 2010 schrieb Yuv:
> > >http://mercurial.selenic.com/wiki/FAQ#FAQ.2BAC8-Terminology.What_are_...
> > >
> > > on_numbers.2C_changeset_IDs.2C_and_tags.3F
> > 
> > Thanks, I use this value now. Should I commit? Not everyone may like the
> > revision number as a patch value in package name.
> 
> how about posting a patch?  I am not sure I understand your
> implementation just based on the description.  Why would there be a
> problem with a revision *number* as a patch value in package name?
> IIRC this is what we did so far with SVN.  It would be different if it
> is a changeset ID.

Hi Yuv,
at least in this CMakeLists.txt the value of V_PATCH was hardcoded to "0".

Changing it to the revision gives me what I wanted.
There is one glitch:
If the environment variable is not set to "en", then the matching line for the 
revision may not be found.

Matching line:
"^parent: *[^0-9]*\([0-9]+\):\([a-z0-9]+\)"
maybe we could change it to
"^.*: *[^0-9]*\([0-9]+\):\([a-z0-9]+\)"
or
"^.*: *[^0-9]*\([0-9]+\):\([a-z0-9]+\) *tip"
to make it language independent.

(This is what I get calling hg summary:
Vorgänger: 4030:1a22b25204ef tip
 [OSX] make versioning work in XCode according to Mercurial
Zweig: default
Übernehme: 1 modifiziert, 1 unbekannt
Aktualisiere: (aktuell)
)

> Yuv

Kornel
-- 
Kornel Benko
kornel.be...@berlin.de
diff -r 1a22b25204ef CMakeLists.txt
--- a/CMakeLists.txt	Mon May 17 20:22:42 2010 +0200
+++ b/CMakeLists.txt	Tue May 18 11:27:00 2010 +0200
@@ -54,6 +54,13 @@
   SET(HUGIN_DEVELOPMENT_VERSION 0)
 ENDIF()
 
+# message(STATUS "CPACK_PACKAGE_VERSION_PATCH = " ${CPACK_PACKAGE_VERSION_PATCH})
+
+# Using the revision number as the patch-value in package name
+if (CPACK_PACKAGE_VERSION_PATCH GREATER ${V_PATCH})
+  set(V_PATCH ${CPACK_PACKAGE_VERSION_PATCH})
+endif()
+
 # version to display
 IF (HUGIN_DEVELOPMENT_VERSION EQUAL 1)
   set(DISPLAY_VERSION "Pre-Release ${V_MAJOR}.${V_MINOR}.${V_PATCH}.${HUGIN_WC_REVISION}")
@@ -498,6 +505,7 @@
  )
 set(CPACK_DEBIAN_PACKAGE_DEPENDS "libpano13 (>=2.9.15)")
 INCLUDE(CPack)
+message(STATUS "V_PATCH = " ${V_PATCH})
 
 ##
 ## Uninstall Taget


signature.asc
Description: This is a digitally signed message part.

[hugin-ptx] Re: Windows 64-bit Build

[dex Otaku]

Hey all,

This may seem like a naïve non-developer question, but how much
utility is gained with Hugin being 64-bit when enblend/enfuse isn't?

The only problems I run into with Hugin currently are caused by
enblend running out of memory when trying to use --fine-mask [because
without it, banding or black lines sometimes occur].

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Hugin Mercurial Repo - Please Test and Help

[Harry van der Wolf]

Hi Yuv,


2010/5/18 Yuv 

>
> * KImageFuser
>
>  - I did not do anything. Since Harry has been on Mercurial for it
> for more than two months, I assume it already lives on Hg somewhere
> else?
>
>
No, it's not. I mentioned that ImageFuser is on Mercurial for 2 months.
KImageFuser is it's Kommander KDE linux (little) brother that started when I
had no macbook anymore.
It is still on SVN. However, I have a local svn2hg repository on my server
and I work with hg on my "local" repositories and then with svn to the
central repository. As I hardly touch linux anymore I want to do some final
functionality build-in and than it's done for me.
It is no problem for me though to convert it myself to mercurial. I just
make it a SourceForge new mercurial repo.

Harry

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx