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

[Yuv]

Hi all,

I've spared some time to work on the Hg migration. Below you will
find:
1. the current Hg repo with short instructions how to test it
2. a status report and what needs to be done
3. a detailed report of how I got here
4. suggested next steps
5. further readings / references

All of the instruction below are for K/Ubuntu and for the command
line.


1. CURRENT HG REPO

to use/test it you will need to install Mercurial. Run the command
`sudo apt-get install mercurial`

you want to edit your ~/.hgrc file to enable some useful extensions.
Run the command `pico ~/.hgrc`, add the following lines and save:

[extensions]
convert =
hgext.hgk =

download (48MB): http://photopla.net/hugin/hugin.hg.bz2

it will uncompress to about 119MB with the command `tar xvjf
hugin.hg.bz2`

Initially the folder contains only an invisible folder - the
repository's full history. To check out the latest version (equivalent
to SVN trunk at revision 5149), change into the folder and issue the
command `hg co -c`

If you want to check out a specific revision, the command is `hg co -c
-r <REV>` where <REV> identifies the changeset and is substituted by
either the revision number or, preferably, the SHA1 ID (a 12 digits
string representing an hexadecimal number) identifying the changeset.

Note that the revision number is sequential but it is (a) completely
unrelated to the SVN revision number and (b) can change between
different Hg repositories, hence it is better to use the SHA1 ID as a
reference, e.g. `hg co -c -r 421ac6996432` will bring you back to
Hugin 0.7.0 rc6 (which IIRC was the final 0.7.0).

`hg help` is your friend.

`hg log` will list you the logged changes. To know more about this
command, type `hg help log`.

`hg tags` lists the tags and `hg branches` lists the branches that are
available in the repository. With the command `hg view` you can
graphically display the whole tree.


2. STATUS REPORT

The current repo is a fairly complete history of Hugin, plus branches
that have not been moved to the obsolete branches folder yet. The
branches give you the opportunities to try how branches behave in hg.
The intention, for the actual migration, is to migrate only trunk.

The heavy movies and PDF files have been filtered out (details below).

Keyword replacement has not been implemented yet.

The cmake build system has not been touched yet and is likely not to
work exactly as intended (versioning!)


3. HOW TO REPRODUCE

You will need subversion and mercurial. Run the command `sudo apt-get
install subversion mercurial`

You will need the following two files:
* http://photopla.net/hugin/hugin_contrib.txt (maps SVN to Hg
contributors)
* http://photopla.net/hugin/hugin_filemap.txt (maps path to exclude/
include, particularly the movies and PDFs)

Mirror locally the Hugin subversion repository with the following
commands:

svnadmin create hugin-mirror
cd hugin-mirror
echo '#!/bin/sh' > hooks/pre-revprop-change
echo 'exit 0' >> hooks/pre-revprop-change
chmod +x hooks/pre-revprop-change
export FROMREPO=https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/
export TOREPO=file://`pwd`
svnsync init ${TOREPO} ${FROMREPO}
svnsync --non-interactive sync ${TOREPO}

If the sync is aborted, you will need to reset the lock state and
restart:

svn propdelete svn:sync-lock --revprop -r 0 ${TOREPO}
svnsync --non-interactive sync ${TOREPO}

Now that you have a local mirror, there are multiple ways to convert
the SVN repository to Hg. The one that worked best so far for me is
the following command:

hg convert \
--branchsort \
--config convert.svn.branches=hugin/branches \
--config convert.svn.tags=hugin/tags \
--config convert.svn.trunk=hugin/trunk \
--authors hugin_contrib.txt \
--filemap hugin_filemap.txt \
--rev 5149 \
hugin-mirror

it will create a folder hugin-mirror-hg, which is equivalent to the
download at part 1 of this mail.


4. SUGGESTED NEXT STEPS

the most important next step is to get versioning in cmake working.
currently cmake appends the svn revision number to the manually set
version number. ideally we'd need to substitute the SHA1 ID for the
*parent* changeset.

then we'd need some reports that this hg repo works, i.e. that *you*
can use it, extract and build the tip out of it, make and commit
changes, clone it, have local branches of your own, switch between
them.

some further clean ups are nice to have but optional, such as tagging
newer hugin versions. since the current release cycle works separately
from trunk, it has not been converted, nor have been the different
release branches/tags.

if the developers are comfortable with the Hg repo (I suspect we'll
need at least another iteration), we can freeze SVN to read-only
access and upload the Hg repo to SourceForge and make it the official
Hugin repo. Then developers will start pushing changes to that repo.

There is a time squeeze (GSoC coding is due to start soon and we'd
like students to work with Hg) and my spare time is close to zero for
the next three weeks, so either somebody can step in (I've documented
everything in this mail and I am willing to help / answer questions /
advance the issue in the little time I have), or we work with a less
than optimal repo and clean it up as we go.


5. FURTHER READINGS / REFERENCES

Versioning: http://mercurial.selenic.com/wiki/VersioningWithMake
Keyword Substitution: http://mercurial.selenic.com/wiki/KeywordExtension
Why not Keyword Substitution: http://mercurial.selenic.com/wiki/KeywordPlan

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

[Lukáš Jirkovský]

Wow!
That's an impressive job you've done. I think I can help here, but not
before the next week.

Lukas

[Thomas Modes]

Hi Yuv,

I tested your hg repository on windows. First simple tests were sucessful.

> 4. SUGGESTED NEXT STEPS
>
> the most important next step is to get versioning in cmake working.
> currently cmake appends the svn revision number to the manually set
> version number. ideally we'd need to substitute the SHA1 ID for the
> *parent* changeset.
>
>

Attached is a patch for the CMake system to work with mercurial (idea
taken from enblends cmake system, thankes Kornel). 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).

> then we'd need some reports that this hg repo works, i.e. that *you*
> can use it, extract and build the tip out of it, make and commit
> changes, clone it, have local branches of your own, switch between
> them.
>

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.

Concerning keywords, maybe we should drop this concept and use hg to
keep track of changes, as in your link mentioned.

Thomas

[Yuval Levy]

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 to
http://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 from http://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

[Harry van der Wolf]

Hi Yuv,

 

Thanks again for your efforts and support in trying to improve hugin.

2010/5/11 Yuval Levy <goo...@levy.ch>

 

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)?

 

Yes, the Hg repo works well on OSX. I reworked your step 1. (current HG repo). This works fine. I did some minor tests like committing small (nonsense) changes to my local repo and that works fine too. I did not push off course.
A necessary requirement on OSX is also to include the username either in ~/.hgrc (hidden file) or directly in the local hg repo folder in .hg/hgrc (normal file in hidden directory). Choose what you want if you want to distinguish between repos or userids at different servers (SourceForge versus Berlioz for example).
So it needs:
[ui]
username = Peter Parker <spid...@gmail.com>

 

Your step 3  (How to reproduce) only works up and including the "svnsync --non-interactive sync ${TOREPO}".
To start with: On OSX the "perforce" toolset (p4, p4merge, etc.) needs to be installed as a requirement as well.

The "hg convert ..." step does not work as my system is a mixed python-6 system (with some python-5 leftovers). p4 generates loads of errors and then errors out. I fiddled a little with it but could not get it to work. I don't want to install python-4 if that's the issue (hence the name??), but that's just a wild guess.

 

 

More or less OT: I already use hg for 2 months for ImageFuser on Sourceforge. Until so far I'm happy with it and until so far I can report that Hg as such works fine on OSX (and so is the enblend hg repo).

 

Harry

[Yuv]

Thanks everybody for testing/feedback.

On May 11, 12:22 pm, Harry van der Wolf <hvdw...@gmail.com> wrote:
> A necessary requirement on OSX is also to include the username either in
> ~/.hgrc (hidden file) or directly in the local hg repo folder in .hg/hgrc
> (normal file in hidden directory). Choose what you want if you want to
> distinguish between repos or userids at different servers (SourceForge
> versus Berlioz for example).
> So it needs:
> [ui]

> username = Peter Parker <spider...@gmail.com>

yes, it is good practice in Linux too, else it uses the local user
information with maybe some unintended consequences.

> Your step 3  (How to reproduce) only works up and including the "svnsync
> --non-interactive sync ${TOREPO}".
> To start with: On OSX the "perforce" toolset (p4, p4merge, etc.) needs to be
> installed as a requirement as well.
> The "hg convert ..." step does not work as my system is a mixed python-6
> system (with some python-5 leftovers). p4 generates loads of errors and then
> errors out. I fiddled a little with it but could not get it to work. I don't
> want to install python-4 if that's the issue (hence the name??), but that's
> just a wild guess.

my mistake - I reconstructed all of my work on a newly set up system
(Kubuntu 10.4 LTS) and I also had to perform a `sudo apt-get install
python-subversion` to make it work. However I am not sure about
perforce, sorry. OSX development is still unknown territory for me.

I'm ready to go. After posting this message I will start disabling SVN
write access to all contributors. Then I will update my SVN mirror to
the latest revision, do the conversion to Mercurial, test it, and push
it to Sourceforge. My apology to all developers and translators for
the service disruption, which I hope will be short and painless. If
everything works as planned we should be back in business in a few
hours, officially on mercurial.

Because the cost is minimal (4MB out of a total of 67MB for the whole
repository), I will not be filtering away development branches that
still have code that might be interesting for trunk integration
(gsoc2008_masking and gsoc2008_feature_matching) and I will add all
the release branches we had so far (2009.2 2009.4 2010.0). We'll need
to rewrite the wiki documentation about the development branching
process and about the release branching process, and we'll need to
take care of a few other small details, but overall I think we're on
track for a smooth migration to Mercurial. I'll get back later with a
status update.

Yuv

[Yuv]

On May 16, 4:01 pm, Yuv <goo...@levy.ch> wrote:
> I'll get back later with a status update.

SVN write permission have been revoked to everybody except Bruno (the
Hugin website with its automated update still runs off SVN, we'll need
to bring that process up to date to do the same with Hg, as done for
the Enblend website) and myself (to add the last bits of information
about the migration once the migration is done). Updating permissions
on Sourceforge is ... suboptimal (understatement) and slow, but at
last it is done.

Whoever had SVN write access now has Hg write access.

I am currently pushing the new repo to Sourceforge. I am using the `hg
push` command which is much slower than simply rsyncing all the files,
but it is also cleaner. It will take some time. Once this is done,
I'll edit the repo's .hgrc file for email notifications and other
stuff.

Also, after the repo is updated, everybody will have read access to it
via the web at
http://hugin.hg.sourceforge.net/hgweb/hugin/hugin/

Read-only access, for everybody building Hugin from the repo:

`hg pull http://hugin.hg.sourceforge.net:8000/hgroot/hugin/hugin`

Everybody who had write access to SVN now has write access to Hg. Pull/
push from/to the following URL:

ssh://<USERNAME>@hugin.hg.sourceforge.net/hgroot/hugin/hugin

replace <USERNAME> with your Sourceforge user name.

I don't know how long the push operation will still need, nor if it
will be successful. If you're in a hurry, check out the above linked
web URL. I'm going out for a job now. Will be back in 2-3 hours to
continue the migration. If everything went as expected, by then the
new Hg repo is up and running and available for use.

When I will be back I will set up email notification and other
details.

[Bart van Andel]

Hey Yuv,

Thanks for all your effort! I must say to me the HG web viewer looks a
lot cleaner than the SVN web viewer. One interesting thing I noticed:
the latest entry in the "changes" table shows

"in the future convert-repo update tags default tip"

Didn't know HG has supernatural powers :) Does this have to do with
timezone settings or incorrect server time? I'm currently at CET
summertime (GMT+2), it's 0:19 here while the latest change shows 0:31
+0000. Or is the job still running?

Looking forward to experiment with the HG repo!

--
Bart

On 16 mei, 22:43, Yuv <goo...@levy.ch> wrote:
> On May 16, 4:01 pm, Yuv <goo...@levy.ch> wrote:
>
> > I'll get back later with a status update.
>
> SVN write permission have been revoked to everybody except Bruno (the
> Hugin website with its automated update still runs off SVN, we'll need
> to bring that process up to date to do the same with Hg, as done for
> the Enblend website) and myself (to add the last bits of information
> about the migration once the migration is done). Updating permissions
> on Sourceforge is ... suboptimal (understatement) and slow, but at
> last it is done.
>
> Whoever had SVN write access now has Hg write access.
>
> I am currently pushing the new repo to Sourceforge. I am using the `hg
> push` command which is much slower than simply rsyncing all the files,
> but it is also cleaner. It will take some time. Once this is done,
> I'll edit the repo's .hgrc file for email notifications and other
> stuff.
>
> Also, after the repo is updated, everybody will have read access to it

> via the web athttp://hugin.hg.sourceforge.net/hgweb/hugin/hugin/

>
> Read-only access, for everybody building Hugin from the repo:
>

> `hg pullhttp://hugin.hg.sourceforge.net:8000/hgroot/hugin/hugin`

[Yuv]

Hey Bart,

Bart van Andel wrote:
> Thanks for all your effort! I must say to me the HG web viewer looks a
> lot cleaner than the SVN web viewer. One interesting thing I noticed:
> the latest entry in the "changes" table shows
>
> "in the future convert-repo update tags default tip"
>
> Didn't know HG has supernatural powers :) Does this have to do with
> timezone settings or incorrect server time? I'm currently at CET
> summertime (GMT+2), it's 0:19 here while the latest change shows 0:31
> +0000. Or is the job still running?

I just came home and went on to look if the job completed. On the web
viewer it says "55 minutes ago". I have no clue about the "in the
future" thing. Yes, the view is really nicer and IMHO more informative
than SVN web view as implemented on Sourceforge.

It shows tags in a yellow box. The tip of each branch in a green box.
The tip of the default branch, which is also commonly referred to as
the tip, is also a tag. It is easy to drill down into the individual
changes, which helps a lot reading and learning the code.

> Looking forward to experiment with the HG repo!

go ahead, it's operational and live. we still need to commit Thomas'
patch to the CMake build, and I will have to edit the repository
settings. But first: I am starving. I'll be back after dinner and a
little bit of family quality time.

[Tduell]

Hullo All,
I have been trying to come up to speed on how to use mercurial, and
thought I should test making a clone repo (working copy).
I used...

'[terry@phenom hugin-trunk-hg]$ hg clone http://hugin.hg.sourceforge.net:8000/hgroot/hugin/hugin
trunk'

which appeared to work OK, and didn't take too long.
I did run into a spot of bother when I tried my usual procedure to
build a package.
'cmake .' returned the following error...

CMake Error at CMakeLists.txt:51 (FILE):
file Internal CMake error when trying to open file:
/home/terry/hugin-trunk-hg/trunk/rev.txt for reading.

The file rev.txt isn't in my local trunk.
Is this an error in the way the mercurial repo is set up, or something
that has resulted from the way I have gone about getting my working
copy?

Cheers,
Terry

[Yuv]

Hi Terry,

thanks for testing.

On May 16, 9:47 pm, Tduell <tdu...@iinet.net.au> wrote:
> The file rev.txt isn't in my local trunk.
> Is this an error in the way the mercurial repo is set up, or something
> that has resulted from the way I have gone about getting my working
> copy?

the file rev.txt is generated by CMake. Currently the generation
depends on svn, hence the error when it is missing.

I have committed Thomas' patch in my local Hg repo. I'll push it to
the SF Hg repo after I have set up it's hgrc file with the email
notifications etc. - this I am trying to do as I write. Must be done
via SF's shell access and I will use the work I did for enblend as a
template. However the nature of SF shell access is that I can only
access one project at a time; and I can only have one shell at a time;
so the process is time consuming. Bear with me while I'm at it.

Thanks
Yuv

[Yuv]

On May 10, 2:15 pm, Thomas Modes <Thomas.Mo...@gmx.de> wrote:
> Attached is a patch for the CMake system to work with mercurial (idea
> taken from enblends cmake system, thankes Kornel). 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).

patch committed and pushed to the repo on SF, thanks Thomas. The
notify hook had a problem so I am not sure that an email has been sent
to hugin-cvs as it should have. I have tried to fix it in the hgrc -
will need another commit / push to test.

Yuv

[Tduell]

Hullo Yuv,

On May 17, 1:28 pm, Yuv <goo...@levy.ch> wrote:
[snip]

> patch committed and pushed to the repo on SF, thanks Thomas.  The
> notify hook had a problem so I am not sure that an email has been sent
> to hugin-cvs as it should have. I have tried to fix it in the hgrc -
> will need another commit / push to test.

I just did an update to my working copy, and 'cmake .' now generates
rev.txt, but doesn't echo the revision number while it does it's
stuff.
Not sure if that is an issue, but it does seem a good idea to have the
revision number echoed to screen.
For the record the revision number is 645a8acc3d37
Under svn 'make package_source' generated a tar.gz archive of 11.6MB
(svn5155). The same procedure now generates an archive of 60.5MB which
includes the '.hg' dir of 49.9MB. Is it necessary for '.hg' to be
included in the source package?

Cheers,
Terry

[Bruno Postle]

On 17 May 2010 05:00, Tduell <tdu...@iinet.net.au> wrote:

> Under svn 'make package_source' generated a tar.gz archive of 11.6MB
> (svn5155). The same procedure now generates an archive of 60.5MB which
> includes the '.hg' dir of 49.9MB. Is it necessary for '.hg' to be
> included in the source package?

cmake needs to be told to ignore the .hg folder. At the end of the
CMakeLists.txt file there is a list of patterns, you need to add
another one for '/\.hg/'.

Then you can create a patch with `hg diff` and send it here.

--
Bruno

[Kornel Benko]

Am Montag 17 Mai 2010 schrieb Yuv:
> On May 10, 2:15 pm, Thomas Modes <Thomas.Mo...@gmx.de> wrote:
> > Attached is a patch for the CMake system to work with mercurial (idea
> > taken from enblends cmake system, thankes Kornel). 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).
>
> patch committed and pushed to the repo on SF, thanks Thomas. The
> notify hook had a problem so I am not sure that an email has been sent
> to hugin-cvs as it should have. I have tried to fix it in the hgrc -
> will need another commit / push to test.

Nice work.
I converted to mercurial and tried to compile. Thanks to Thomas it compiled painlessly.
Also the installation of the created package "hugin-2010.1.0-Linux.deb" done without problems.

What I would like to see is some way of automatic versioning. Don't know how to do it with mercurial.
(Under svn I could have used output from svnversion to create a package like "hugin-2010.1.5138-Linux.deb)

> Yuv

Kornel
--
Kornel Benko
Kornel...@berlin.de

[Yuv]

On May 17, 1:00 am, Tduell <tdu...@iinet.net.au> wrote:
> Not sure if that is an issue, but it does seem a good idea to have the
> revision number echoed to screen.

versioning in CMake is still on the TODO list. Information at the
following URL:

http://mercurial.selenic.com/wiki/VersioningWithMake

> For the record the revision number is 645a8acc3d37

technically that's the changeset ID. It can be used almost
interchangably with the revision number on all Mercurial commands.
There are also revision numbers, but they take a different, *local*
meaining in Mercurial while the changeset ID is *global*. Another
difference between revision number and changeset ID is that while
revision numbers are incremental (but vary across copies of the repo),
changest IDs are not incremental (but stay constant across copies of
the repo).

http://mercurial.selenic.com/wiki/FAQ#FAQ.2BAC8-Terminology.What_are_revision_numbers.2C_changeset_IDs.2C_and_tags.3F

On May 17, 6:30 am, Bruno Postle <brunopos...@googlemail.com> wrote:
> On 17 May 2010 05:00, Tduell <tdu...@iinet.net.au> wrote:
>

> > includes the '.hg' dir of 49.9MB. Is it necessary
>

> cmake needs to be told to ignore the .hg folder. At the end
> of the CMakeLists.txt file there is a list of patterns, you
> need to add another one for '/\.hg/'.

Oups, sorry, forgot this one. Good time for a short committer
tutorial. After editing the code:

`hg status` will show the modified files (marked with an M) and the
new files (with a question mark)

if you want to add files with a question mark to your next commit, use
`hg add`

when you're happy with the list of files to be committed, hit `hg ci`

now the change is committed to your local repo. To push it to the
global repo (or to another repo), use the command `hg push` - without
arguments or with the appropriate URL.

at the same time I used this to test that the email notification to
hugin-cvs works. It does :)

On May 17, 6:40 am, Kornel Benko <Kornel.Be...@berlin.de> wrote:
> What I would like to see is some way of automatic versioning.
> Don't know how to do it with mercurial.
> (Under svn I could have used output from svnversion to create a package like "hugin-2010.1.5138-Linux.deb)

the link to versioning is above, as are some of the info to the
topic. We'll have to deal with two issues:

1* revision numbers are related to the specific (local) repo. there
is no guarantee that if you and I make a package of the same code,
that it will have the same rev-nr. It will have the same changeset
ID. Rev-nr could be different e.g. because we both have local
development branches (`hg clone`) or have done different operations on
our local default branch that we have not pushed/synced with the SF
central repo.

2* easy: because the SVN->hg conversion process filtered out non-Hugin
revisions, the current Hg rev-nr is < SVN rev-nr. This will be solved
automatically with the next Hugin version-nr bump.

However *1* will not solve without some coordination, e.g. packagers'
attention to always make packages from a clean and neat greenfield
checkout from the SF repo; or at least from the same local repo copy
across a single development cycle (between version number bumps).

For the purpose of bug reporting, the changeset ID is more precise and
important and should be displayed to the user instead of the rev-nr.

Thank you all for your feedback/testing.

[Tom Glastonbury]

I've successfully produced a clean 64-bit build from Hg using MSVC2008,
based on changeset 4024 (645a8acc3d37). In case anyone wants to play
with it, I've posted it to the usual place ( http://tg73.net ). There
were no problems.

Tom

[Kornel Benko]

Am Montag 17 Mai 2010 schrieb Yuv:

> http://mercurial.selenic.com/wiki/FAQ#FAQ.2BAC8-Terminology.What_are_revisi
> 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.

[Harry van der Wolf]

The cmake build works fine on OSX.

XCode 32/64 bit build works fine as well except from the versioning. I need to do some manual "fixing" right now. I assume that patch will be my first hg push.

Harry

[Harry van der Wolf]

Now it seems that Tom and I got in each others way.


Now I removed my hg hugin trunk and did again a:
'hg clone http://hugin.hg.sourceforge.net:8000/hgroot/hugin/hugin hugin'

I cd-ed into hugin and to be sure I did a
 'hg pull'
then I changed (with vi) in "src/hugin_config.h.in.cmake" the comment:
/* this is a hg checkout, tag is as such
 * all builds from HG will be considered development versions
 */
(was SVN, changed to hg). This seemed a safe change to me.
Then I did a:
hg commit -m "\"translate\" SVN to hg in hugin_config.h.in.cmake"

and then:
hg push ssh://harryva...@hugin.hg.sourceforge.net/hgroot/hugin/hugin

and then I got:
The authenticity of host 'hugin.hg.sourceforge.net (216.34.181.121)' can't be established.
RSA key fingerprint is 86:7b:1b:12:85:35:8a:b7:98:b6:d2:97:5e:96:58:1d.
Are you sure you want to continue connecting (yes/no)? yes
harryva...@hugin.hg.sourceforge.net's password:
remote: Warning: Permanently added 'hugin.hg.sourceforge.net' (RSA) to the list of known hosts.
pushing to ssh://harryva...@hugin.hg.sourceforge.net/hgroot/hugin/hugin
searching for changes
abort: push creates new remote heads!
(did you forget to merge? use push -f to force)

Now only the last 2 lines matter. The first seven lines are obvious.
So I checked the website and it turns out that Thomas did a push at the same time I did my changes.

So I did a
'hg merge'
and then a
'hg commit'
as hg told me to do so:
Then I did again the
hg push ssh://harryva...@hugin.hg.sourceforge.net/hgroot/hugin/hugin

Now I now have the idea that I redid/recommitted Thomas changes.

Can anybody explain whether this is correct behavior or what I did wrong?
And how we should handle this in the future?

[Kornel Benko]

Am Montag 17 Mai 2010 schrieb Harry van der Wolf:
...
>*abort: push creates new remote heads!

>(did you forget to merge? use push -f to force)

...

> So I did a
> 'hg merge'
> and then a
> 'hg commit'
> as hg told me to do so:
> Then I did again the
> hg push ssh://harryva...@hugin.hg.sourceforge.net/hgroot/hugin/hugin
>
> Now I now have the idea that I redid/recommitted Thomas changes.
>
> Can anybody explain whether this is correct behavior or what I did wrong?

I have seen this often at enblend, it made me cry ..

> And how we should handle this in the future?

I always try to
hg pull
hg update

before commiting. This above mentioned behaviour was one thing I newer liked.

[T. Modes]

Hi Yuv,

>
> patch committed and pushed to the repo on SF, thanks Thomas. The
> notify hook had a problem so I am not sure that an email has been sent
> to hugin-cvs as it should have. I have tried to fix it in the hgrc -
> will need another commit / push to test.
>

tested official repository now. The first pull took about 2 hours. Is
this normal or because of high traffic on the sf server?
I fixed in the mean time some more issues.

@ Harry
I think, you did the right thing. Have a look on the graphic
representation of the repo
http://hugin.hg.sourceforge.net/hgweb/hugin/hugin/graph
There you can see that with your merge you merged the 2 "heads" (one
with my changes and the one with your changes). I think, we will see
this more in the next time.

Thomas

[Harry van der Wolf]

Hi Kornel,

2010/5/17 Kornel Benko <Kornel...@berlin.de>

Am Montag 17 Mai 2010 schrieb Harry van der Wolf:
...
>*abort: push creates new remote heads!

>(did you forget to merge? use push -f to force)

...

> So I did a
> 'hg merge'
> and then a
> 'hg commit'
> as hg told me to do so:
> Then I did again the
> hg push ssh://harryva...@hugin.hg.sourceforge.net/hgroot/hugin/hugin
>
> Now I now have the idea that I redid/recommitted Thomas changes.
>
> Can anybody explain whether this is correct behavior or what I did wrong?

I have seen this often at enblend, it made me cry ..

OK, now I can go to sleep tonight without feeling to insecure.
I do think this will happen more often. In your case I think you worked on the cmake part whereas Christopher worked on the automake part. So even though hg complained I think there were never real conflicts.
We will see what happens to the hg trunk when developers "touch" the same files. hg should resolve that correctly but we (well, that is: I) need to have clear what to do in such a situation. I will re-read the documentation.

 

> And how we should handle this in the future?

I always try to
       hg pull
       hg update

before commiting. This above mentioned behaviour was one thing I newer liked.

Well, this is exactly what I mean if you do it like that. Your changes are not yet committed and the next set of changes from the trunk will be rolled over them. I think that went OK as Christoph and you were working on different parts.
I think you should commit your changes first and then do the:
hg pull
hg update
hg merge
hg push
(or so).

As mentioned: I will re-read the hg documentation.
 

Harry

[Harry van der Wolf]

Hi Thomas,

2010/5/17 T. Modes <Thomas...@gmx.de>

@ Harry
I think, you did the right thing. Have a look on the graphic representation of the repo http://hugin.hg.sourceforge.net/hgweb/hugin/hugin/graph
There you can see that with your merge you merged the 2 "heads" (one with my changes and the one with your changes). I think, we will see this more in the next time.

Thomas

Crossing mails. crossing code. Busy traffic tonight.
Another confirmation. thanks. I will have a good sleep tonight.

Harry

[T. Modes]

Hi Yuv,

>> patch committed and pushed to the repo on SF, thanks Thomas. The
>> notify hook had a problem so I am not sure that an email has been sent
>> to hugin-cvs as it should have. I have tried to fix it in the hgrc -
>> will need another commit / push to test.

I forget one comment. Maybe you or Bruno should commit one last commit
to the subversion repository, which breaks the cmake build for
subversion and report, that we switched to mercurial (something like
"MESSAGE(FATAL_ERROR "Subversion repository is out of sync, please
checkout the code from mercurial repository")" at the beginning of the
cmakefile. So users, which checkout from subversion and don't read the
mailing list, get also a feedback.

[Bruno Postle]

On Mon 17-May-2010 at 21:25 +0200, Thomas Modes wrote:
>
>I forget one comment. Maybe you or Bruno should commit one last
>commit to the subversion repository, which breaks the cmake build for
>subversion and report, that we switched to mercurial

Ok, done. The SVN trunk now intentionally fails to build (the error
message tells you how to skip the warning and continue anyway).

The new mercurial repository works fine for me, thanks for doing
this Yuval. I can update and create tarballs which build ok.

--
Bruno

[Yuv]

Hallo Kornel,

On May 17, 10:30 am, Kornel Benko <Kornel.Be...@berlin.de> 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.

[Yuv]

On May 17, 3:07 pm, "T. Modes" <Thomas.Mo...@gmx.de> wrote:
> tested official repository now. The first pull took about 2 hours. Is

> this normal?

sounds slow to me. I'm running `hg clone` now, will report my time
later.

> @ Harry
> I think, you did the right thing. Have a look on the graphic

> representation of the repohttp://hugin.hg.sourceforge.net/hgweb/hugin/hugin/graph

> There you can see that with your merge you merged the 2 "heads" (one
> with my changes and the one with your changes). I think, we will see
> this more in the next time.

yes, I think we will see more of these kind of "minor branching" and
there is nothing wrong with them. Doing an `hg pull && hg up` before
committing as suggested by Kornel is a good reflex *if* one is hooked
to the net. Otherwise, merging at the next possible occasion like
Harry did is the right thing to do. We need to learn to live with Hg.

Yuv

[Yuv]

On May 17, 10:59 pm, Yuv <goo...@levy.ch> wrote:
> sounds slow to me. I'm running `hg clone` now, will report my time
> later.

done (and it may have been waiting for me to check on it for a few
minutes)

[Yuv]

On May 17, 6:45 pm, Bruno Postle <br...@postle.net> wrote:
> On Mon 17-May-2010 at 21:25 +0200, Thomas Modes wrote:
>
> >I forget one comment. Maybe you or Bruno should commit one last
> >commit to the subversion repository, which breaks the cmake build for
> >subversion and report, that we switched to mercurial
>
> Ok, done.  The SVN trunk now intentionally fails to build (the error
> message tells you how to skip the warning and continue anyway).

was on my TODO list and I did not even get to it. Thanks for doing
it.

> The new mercurial repository works fine for me, thanks for doing
> this Yuval.  I can update and create tarballs which build ok.

Good. I've migrated the other bits and pieces from the Hugin SVN repo
and will upload them to separate Hg repos on SF later this week:

* 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?

* autopano-sift-C
* lensdb
* libpanorama
* panoglview

- Will upload to its own Hg repo, with commit messages to hugin-cvs

* htdocs

- Will upload too. Moreover, the automatic update from repo will
have to be re-implemented:

cd
hg clone http://hugin.hg.sourceforge.net:8000/hgroot/hugin/hugin-web

cd hugin-web && hg pull && hg up && rsync -rl --delete --
exclude=".hg*" ../hugin-web/ <USER>,hu...@web.sourceforge.net:/home/
groups/h/hu/hugin/htdocs/

Make sure <USER> is a project member and has the server`s fingerprint
in the approved hosts. Then set up a cron job

Yuv

[Harry van der Wolf]

Hi Yuv,

2010/5/18 Yuv <goo...@levy.ch>

* 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

[Kornel Benko]

Am Dienstag 18 Mai 2010 schrieb Yuv:
> Hallo Kornel,
>
> On May 17, 10:30 am, Kornel Benko <Kornel.Be...@berlin.de> 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

[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

[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.

[Bruno Postle]

On 18 May 2010 10:50, Kornel Benko <Kornel...@berlin.de> 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).

[Yuv]

Hoi Harry

On May 18, 3:45 am, Harry van der Wolf <hvdw...@gmail.com> 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://US...@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

[Yuv]

On May 18, 6:50 am, Kornel Benko <Kornel.Be...@berlin.de> 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

[Harry van der Wolf]

2010/5/18 Yuv <goo...@levy.ch>

 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 <major version>.<minor version>.<patch>-svn<SVN revision> built by <builder name>

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

[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 <major version>.<minor version>.<patch>-svn<SVN revision> built by
> <builder name>
> 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 <builder name> 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 <major version>.<minor version>.<patch>-hg<HG repo><HG revision> built
by <builder name>

with <HG revision> = rev nr + SHA1ID (4033:a0de66c7eb13) and with <HG repo>
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

[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

[Harry van der Wolf]

2010/5/18 Yuval Levy <goo...@levy.ch>

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 <major version>.<minor version>.<patch>-hg<HG repo><HG revision> built
by <builder name>

with <HG revision> = rev nr + SHA1ID (4033:a0de66c7eb13) and with <HG repo>
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

[Harry van der Wolf]

Hi Yuv,

2010/5/18 Yuv <goo...@levy.ch>

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://US...@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

[Tduell]

Hullo Bruno,

On May 18, 9:17 pm, Bruno Postle <brunopos...@googlemail.com> 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

[Bruno Postle]

On Mon 17-May-2010 at 20:12 -0700, Yuv wrote:
>
>* htdocs
>
> - Will upload too. Moreover, the automatic update from repo will
>have to be re-implemented:

Done, the web-site is now updated from HG rather than SVN. Though
it looks like I don't have permissions to push to hugin-web:

remote: abort: could not lock repository hgroot/hugin/hugin-web: Permission denied

I'm not sure how this can be fixed.

--
Bruno

[Ken Turkowski]

Here's how I got the sources:

echo "username = Hackers Are Us" > ~/.hgrc  # Only needs to be done once (use your name)

hg clone http://hugin.hg.sourceforge.net:8000/hgroot/hugin/hugin hugin

[Bruno Postle]

On Wed 19-May-2010 at 19:20 +0100, Bruno Postle wrote:

>looks like I don't have permissions to push to hugin-web:
>
> remote: abort: could not lock repository hgroot/hugin/hugin-web: Permission denied

Basically only the 'hugin' HG repository is group writable. I got
around this by logging into the sf shell and renaming the
'hugin-web' repository, then recreating it with usable permissions.

Yuval, I think you need to do a `chmod -R g+w` on each of the new
repositories. You can also delete the defunct 'hugin-web.old'
repository.

[Yuv]

On May 19, 7:43 pm, Bruno Postle <br...@postle.net> wrote:
> Yuval, I think you need to do a `chmod -R g+w` on each of the new
> repositories.  You can also delete the defunct 'hugin-web.old'
> repository.

done! have you renamed hugin-web.old, or did you get help from SF's
support? I'd expect that by default all repos (i.e. all folders in
the scm_hg folder) should be group-writeable. Interestingly, the
group's sticky bit is set by default on all folders created in there.
SF's quirks? go figure...

Yuv

[Yuv]

Hi Thomas,

On May 18, 11:45 am, "T. Modes" <Thomas.Mo...@gmx.de> wrote:
> I don't agree. That will create more confusion for developer.

sorry for the confusion. I don't think there is much disagreement
here, just confusion because I did not express my thoughts well.

For developers it is the SHA1 ID that counts. This is what we should
display to the users so that they can report it.

For packaging it is the rev-nr - because packaging requires that newer
versions have higher version number (else the package manager software
complains about replacing the software with an older version). Since
the SHA1 ID is not sequential (and this can not assign a higher number
to a newer version), it should not be used for the package name. The
revision number can be used for the package name.

Yuv

[Yuv]

Hi Ken,

good to see you again!

On May 19, 5:34 pm, Ken Turkowski <realitypix...@gmail.com> wrote:
> Here's how I got the sources:
>
> echo "username = Hackers Are Us" > ~/.hgrc  # Only needs to be done once
> (use your name)
> hg clonehttp://hugin.hg.sourceforge.net:8000/hgroot/hugin/huginhugin

this is read-only as far as SourceForge is concerned, i.e. you can
make local changes and commits with `hg ci` to your local repo, but
you can't `hg push` your changes to the SF repo. To give you write
access to the SF repo I need to know your SF handle. Please post it
here if you wan write access. Then you access the repo with

`hg clone ssh://<SF_HANDLE>@hugin.hg.sourceforge.net/hgroot/hugin/hugin`

Yuv

[Ken Turkowski]

Hi, Yuv,

I'm in between projects now, so I thought I'd get up-to-date with Hugin.

The released Hugin crashes on my Mac in the assistant. I wanted to build the newest, and hope that it will stitch.

If not, I'd like to get it built in XCode, so that I can do some debugging.

There are some compiler problems on the Mac, and I have a fix for it, so please sign me up for source access:

         kturkowski

Mercurial looks suspiciously like git, which I used at the end of last year on a project for Stanford. Git worked fine most of the time, when I was the only one working on a file, but it was hell when several people were working on it simultaneously. With CVS, SVN, and P4, I had no problems by doing frequent updates (4X/day) and checkins at the end of each day, but with Git, I'd occasionally waste a couple of days trying to check stuff in.

I missed the beginning of this thread. How did you happen to choose Mercurial? What is the best mode of development?

Will I need to check out the sources again?

-Ken

On Wed, May 19, 2010 at 7:34 PM, Yuv <goo...@levy.ch> wrote:

Hi Ken,

good to see you again!

On May 19, 5:34 pm, Ken Turkowski <realitypix...@gmail.com> wrote:
> Here's how I got the sources:
>
> echo "username = Hackers Are Us" > ~/.hgrc  # Only needs to be done once
> (use your name)

> hg clone http://hugin.hg.sourceforge.net:8000/hgroot/hugin/huginhugin

this is read-only as far as SourceForge is concerned, i.e. you can
make local changes and commits with `hg ci` to your local repo, but
you can't `hg push` your changes to the SF repo.  To give you write
access to the SF repo I need to know your SF handle. Please post it
here if you wan write access.  Then you access the repo with

`hg clone ssh://<SF_HANDLE>@hugin.hg.sourceforge.net/hgroot/hugin/hugin`

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

[Bruno Postle]

On 20 May 2010 00:51, Yuv <goo...@levy.ch> wrote:
>
> done! have you renamed hugin-web.old, or did you get help from SF's
> support?

I didn't have write permission so I couldn't change or delete the
folder, but I have write access to the parent folder so I can rename
anything in that.

> I'd expect that by default all repos (i.e. all folders in
> the scm_hg folder) should be group-writeable.

Sourceforge...

--
Bruno

[Bruno Postle]

On 20 May 2010 05:05, Ken Turkowski <realit...@gmail.com> wrote:

> I missed the beginning of this thread. How did you happen to choose
> Mercurial? What is the best mode of development?

mecurial and git are very similar, the main advantages for us are that
creating and merging branches with HG is saner than with SVN, it
allows offline working, and that it eliminates our dependence on
sourceforge as a single point of failure.

> Will I need to check out the sources again?

No just edit the .hg/hgrc file to use the ssh:// rather than the
http:// address.

--
Bruno

[Yuv]

Hi Ken,

On May 20, 1:05 am, Ken Turkowski <realitypix...@gmail.com> wrote:
> There are some compiler problems on the Mac, and I have a fix for it, so
> please sign me up for source access:
>          kturkowski

done. thanks for helping out!


> Mercurial looks suspiciously like git

tools of the same generation. Add Bazaar (bzr) to them as well. It
could have been any of them. Mercurial (Hg) was the one that had more
mature GUI clients on multiple platforms. Git depends on the Bourne
Shell and Perl for scripting, while Hg (and bzr) use Python. Bzr came
relatively late to the party and has slightly less support from
project hosting sites. In the end they are all pretty much equivalent
and it is easy to juggle between them. I've known many developers who
for the past 2-3 years had overlaid one of those three tools on top of
Subversion (SVN) - committing to the central SVN repo revisions that
they developed on their local check outs managed with git or Hg. When
I looked into this trio I also tried to convert the Hugin SVN repo
with many of the available tools for all of them and in the end Hg was
the one that worked best for me. <humor>And on the command line hg is
one char less to type than git or bzer</humor>

> Git worked fine most of the time, when I was the
> only one working on a file, but it was hell when several people were working
> on it simultaneously.

Strange - git is used by very large scale projects without significant
problems. Also the concept of simultaneous work shouldn't be critical
since these tools are designed for asynchronous use. May be more of a
local implementation problem than a flaw of git itself.

> With CVS, SVN, and P4, I had no problems by doing
> frequent updates (4X/day) and checkins at the end of each day, but with Git,
> I'd occasionally waste a couple of days trying to check stuff in.

Conceptually, the checkins of SVN are equivalent to checkin+push with
hg; and the checkouts of SVN are equivalent to pull+checkout with hg.
Only pull and push are network operations and only they may be
affected by network conflicts or scalability issues. Checkouts and
checkins are all local to your machine. If they fail, it may be a
problem of the client used. Harry can give you more details about the
client he uses on OSX. On Windows I had good experience with
TortoiseHG - but I have not used Windows for more than six months now.

> I missed the beginning of this thread. How did you happen to choose
> Mercurial?

Some devs were already using a distributed revision control system
(dRCS) on top of SVN. I got to use git during last year's GSoC - Leon
ported FreePV to the VLC media player and I co-mentored. It blew me
away how much easier it is to branch and merge compared to SVN; and
how much more responsive it is to check out / switch branches (no
wonder - the whole repo is on the local HDD, disk access is the limit
rather than network access for SVN). So I did some research, got
community support, we identified and solved the issues, identified the
optimal time for the switch and did it.

I'm writing up more info on my blog. here is the first installment:

http://panospace.wordpress.com/2010/05/19/svn2hg_part1/

> What is the best mode of development?

At the beginning of the work session:
* If you are online do `hg pull` if connected to the net (but it's not
tragic if there is no network)
* do `hg co` right after pulling or if you want to work on a different
branch
During the work session:
* edit the code
* do `hg ci` after every change and document it in the commit
comment. You can commit often, it is faster and more convenient than
with SVN because it is not dependent on the network. *important*: a
commit is only local, on your HDD. To be equivalent to an SVN commit,
you also have to push it (see next steps)
At the end of the work session (or when you've added enough change
that you think is worth backing up / pushing to other developers to
try):
* do `hg pull` again
* do `hg co` again
* if necessary, solve conflicts / merge back to the branch you
intended your change to go to. Because of the asynchronism it is
possible to unintentionally produce an extra branch - in fact,
conceptually every changeset can be seen as a branch. You can see the
status of your local repository with `hg view` (you need to enable the
hgk extension with a line `hgext.hgk =` in the [extensions] section of
your ~/.hgrc file.
* do `hg push` to push the changes that are currently still in your
local repo to the global SF repo (or to any other repo that accepts
changes from you).

the conceptual difference from SVN to Hg is that the network
operations (push/pull) are separate from the revision operations
commit/checkout

we've already experienced some network slow down with SF (Thomas had a
two hours initial pull, while I had a three minutes one) but overall
the system is robust, stable, and ready to take your commits.

enjoy!

[Ken Turkowski]

On May 20, 2010, at 5:05 AM, Yuv wrote:

You can see the
status of your local repository with `hg view` (you need to enable the
hgk extension with a line `hgext.hgk =` in the [extensions] section of
your ~/.hgrc file.
* do `hg push` to push the changes that are currently still in your
local repo to the global SF repo (or to any other repo that accepts
changes from you).

Is there any way of increasing the font size?

-Ken

[Yuval Levy]

On May 20, 2010 07:01:23 pm Ken Turkowski wrote:
> Is there any way of increasing the font size?

I did a little research and found that in Linux it stores the font settings in
~/.hgk

Let us know if it is the same in OSX. And those on Windows, I hope this
finding is helpful for you too?

Yuv

[Harry van der Wolf]

2010/5/22 Yuval Levy <goo...@levy.ch>

On May 20, 2010 07:01:23 pm Ken Turkowski wrote:
> Is there any way of increasing the font size?

I did a little research and found that in Linux it stores the font settings in
~/.hgk

Let us know if it is the same in OSX.  And those on Windows, I hope this
finding is helpful for you too?

Yuv

For the time being hg view is hanging on my system.

I added
[extensions]
hgk =

[hgk]
path=/opt/local/share/mercurial/contrib/hgk

to my .hg.hgrc inside both my hugin and ImageFuser folder and started hg view but on both occasions it is hanging. 
It should be possible to use either Ctrl-{+,-) or Cmd-{+,-} to change the font. Afterwards it should be stored in ~/.gitk, but I don't get that far.

@Ken, can you tell me how you got it running?

Harry

[Yuval Levy]

On May 22, 2010 01:20:22 pm Harry van der Wolf wrote:
> For the time being hg view is hanging on my system.
>
> I added
> [extensions]
> hgk =
>
> [hgk]
> path=/opt/local/share/mercurial/contrib/hgk

what happens if you delete the [hgk] section in ~/.hgrc ?

> It should be possible to use either Ctrl-{+,-) or Cmd-{+,-} to change the
> font. Afterwards it should be stored in ~/.gitk, but I don't get that far.

*blush* I did not even think to explore the user-friendly way. CTRL-{+,-}

~/.gitk ? sounds like an older version of the hgk extension.

Yuv

[Yuv]

On May 20, 8:05 am, Yuv <goo...@levy.ch> wrote:
> Conceptually, the checkins of SVN are equivalent to checkin+push with
> hg; and the checkouts of SVN are equivalent to pull+checkout with hg.

and to complete this: updates of SVN are equivalent to pull+update
with hg.

> At the beginning of the work session:
> * If you are online do `hg pull` if connected to the net (but it's not
> tragic if there is no network)
> * do `hg co` right after pulling or if you want to work on a different
> branch

actually `hg co` the first time and then `hg up` subsequent times. and
if you want to change branches, then list them with `hg branches`;
display the current branch with `hg branch`; set to another branch
with `hg branch <BRANCH>`. The equivalent to SVN's "trunk" is
"default". If `hg branch <BRANCH>` protests, you can override it with
`hg branch -f <BRANCH>`, however it may have good reason to protest
such as an edited file that has not been committed (you want to do `hg
ci` to save your work on the current branch); or there may be some
cruft such as temporary files that make hg think you may have work in
progress that has not been committed yet while you know it is just
cruft (in which case the -f option is OK).

> During the work session:
> * edit the code
> * do `hg ci` after every change and document it in the commit
> comment.  You can commit often, it is faster and more convenient than
> with SVN because it is not dependent on the network. *important*: a
> commit is only local, on your HDD.  To be equivalent to an SVN commit,
> you also have to push it (see next steps)
> At the end of the work session (or when you've added enough change
> that you think is worth backing up / pushing to other developers to
> try):
> * do `hg pull` again
> * do `hg co` again

sorry, this should have read `hg up`

[Harry van der Wolf]

2010/5/22 Yuval Levy <goo...@levy.ch>

On May 22, 2010 01:20:22 pm Harry van der Wolf wrote:
> For the time being hg view is hanging on my system.
>
> I added
> [extensions]
> hgk =
>
> [hgk]
> path=/opt/local/share/mercurial/contrib/hgk

what happens if you delete the [hgk] section in ~/.hgrc ?

Then it doesn't work as it can't find hgk by itself.
I already tried this and also did from /opt/local/bin, which is in my PATH,  a "ln -s /opt/local/share/

mercurial/contrib/hgk".
Then it is in my PATH and I don't need the section but it still hangs.

 

> It should be possible to use either Ctrl-{+,-) or Cmd-{+,-} to change the
> font. Afterwards it should be stored in ~/.gitk, but I don't get that far.

*blush* I did not even think to explore the user-friendly way. CTRL-{+,-}

~/.gitk ? sounds like an older version of the hgk extension.

Yuv

As mentioned: That's how it should work but I didn't get that far so it's only from "hear say".

Harry

[Ken Turkowski]

Here's what I did, Harry,

cat << EOF > ~/.hgrc

[ui]

username = Ken Turkowski <realit...@gmail.com>

ui.verbose = True

[extensions]

hgext.hgk =

[hgk]

path=/opt/local/share/mercurial/contrib/hgk

EOF

[Ken Turkowski]

Neither control nor command + or - worked for me.

I changed the font sizes in ~/.hgk

[Harry van der Wolf]

Hi,

2010/5/26 Ken Turkowski <realit...@gmail.com>

Here's what I did, Harry,

cat << EOF > ~/.hgrc

[ui]

username = Ken Turkowski <realit...@gmail.com>

ui.verbose = True

[extensions]

hgext.hgk =

[hgk]

path=/opt/local/share/mercurial/contrib/hgk

EOF

Mine is the same, apart from the user name.

Weird.

I downloaded Murky, a HG Gui for OSX, and it works fine. I can add multiple trees to Murky, double-click them and have multiple windows with multiple repos (Autopano-sift-C, Hugin and ImageFuser) open.

There are more, also for other OSes. See <http://mercurial.selenic.com/wiki/OtherTools>

Harry

[Tom Sharpless]

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 <goo...@levy.ch> 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

[Yuval Levy]

Hi Tom,

On Friday 28 May 2010 10:53:42 am Tom Sharpless wrote:
> What has happened to the idea of keeping (past and future) releases in
> the SVN repository?

Most voices were against it. I did research on the topic and could probably
implement something if there is a use case with benefit/effort >1.

> Released code needs to
> adhere to a higher standard of buildability and documentation

that's what tarballs are for.

> 2) It validates lots of existing documentation about how to build
> Hugin

yes, the SVN->Hg move has made a lot of documentation outdated.

> the project should be as helpful as possible to people who just want
> to build (and distribute) stable releases

Agree. The use case here would be to update the documentation and help those
people cope with the new repository.

Also: for stable releases there are the tarballs. Nothing has changed with
them AFAIK, other than we forgot the monthly poll to ask ourselves if "trunk"
(or now in new Hg terminology "default") contains enough new features to
warrant branching out a release. The release cycle's documentation [0] is now
technically outdated (need to replace hg commands with svn commands) but the
process is still the same.

> The fact that Hugin releases have so far
> not lived in SVN

actually since 0.8.0 releases have lived in SVN, each with its own branch
according to [0]. After a few fixes and enough polish, the branch florish into
a tarball.

Yuv

[0] http://wiki.panotools.org/Development_of_Open_Source_tools#Release

[Bruno Postle]

On 30 May 2010 01:49, Yuval Levy <goo...@levy.ch> wrote:
>
> Also: for stable releases there are the tarballs. Nothing has changed with
> them AFAIK, other than we forgot the monthly poll to ask ourselves if "trunk"
> (or now in new Hg terminology "default") contains enough new features to
> warrant branching out a release.

Yes, the HG infrastructure is good for continuing with the same
stable-branch system to produce releases (as was done in SVN for
2009.0, 2009.4 and 2010.0).

These 'stable' tar.gz files really are the bits we want packaged for
general release (e.g. Linux distributions, cover discs, and the
Windows/OSX installer you get when you click 'Download' on the Hugin
web-site)

Regarding the next release: the current HG default 'tip' has more than
enough features to be branched for release, and seems stable enough,
but I'm really not keen to drive this process again as I wasn't able
to give it the attention it deserved last time.

--
Bruno

[Yuv]

On Jun 1, 3:49 pm, Bruno Postle <brunopos...@googlemail.com> wrote:
> Regarding the next release: the current HG default 'tip' has more than
> enough features to be branched for release, and seems stable enough,
> but I'm really not keen to drive this process again as I wasn't able
> to give it the attention it deserved last time.

same here - I won't have time or resources to dedicate to driving a
release process in the foreseeable future. I can answer questions
about the process and help somebody who's new at running it, but my
answers are likely to be delayed.

I agree with you that the current hg default 'tip' has more than
enough features to be branched for release, and from the chatter on
this mailing list I have the impression that binary builders and users
are of the same opinion. I see more attention being given to 2010.1
(development) builds than to 2010.0.0, even though the released
tarball have not yet been used to produce a useful Windows 2010.0.0
release (or at least nobody has offered such binaries to be tested and
uploaded to the Hugin homepage).

Branching out 2010.2.0 is a piece of cake with Mercurial, even more
than it was with Subversion. I am not sure how much effort will be
required to clean it up for release. Does anybody have a list of what
bugs are critical? I have seen much bug fixing activity in the
repository (thanks Thomas!) but I have no clue how much additional
effort is still necessary.

Yuv