Hi Yuv
Yuval Levy wrote:
I think it should be the other way around. The choice of DVCS is more critical
than the choice of code hosting provider; and it is also more critical than
the choice of bug tracker and other tools which can also be hosted at
different providers. Hosting is an interchangeable commodity.
That said, the devil lies in the detail and I don't think we have the capacity
at this time to acquaint ourself in detail with other code hosting than
SourceForge. Hence my proposal is to implement Hg on SF. Of course everybody
is free to implement another DVCS at any other hosting provider any time, to
publish their results here, and to see that everybody else learn to use that
alternate hosting provider.
I suppose you have a point, at least do one thing at a time, also below
I have some comments which may indicate that once the conversion is done
to a DVCS, switching to another system can be much easier if that turns
out to be necessary.
Also, regarding the tracker, that may cause a bit of lock-in to sf.net
for now ;-)
And the DVCS should be acceptable to use on all platforms that hugin
developers use.
Yes, which is one of the main reason to choose Hg. Windows support for Hg is
still not perfect, but last time I checked it was more mature than Bzr or Git.
I think this may not be much of an issue if these DVCSes can easily
interoperate, see below.
Thanks also for all the links about repository conversion. The more I think of
it, the more I feel that it is better to leave the past enshrined in SVN
(read-only) and move on to a better future. I see no reasonable use case to
make the effort and add the whole luggage of historic commits to a Hg
repository. But maybe somebody has a case to justify the effort?
Since Pablo had some success converting subversion history to mercurial,
I agree with him that it would be worthwhile to retain at least some
(recent) history. But perhaps more is not too hard and with some
specific dropping of parts of the history not even very large. I'm
keeping my eye open for similar conversions, of which there are many!
KDE is one huge project which has had quite a bit of experience with
conversion from subversion to git, so there may be some way to harness
that experience...
http://blog.hartwork.org/?p=763
http://gitorious.org/svn2git/svn2git
Also conversion/cooperation between mercurial and git is easy to do and
lossless, so using tools made for git (I think this may be more mature
than for mercurial, but I'm not in a position to judge that) can be used
as intermediary step towards a mercurial repository and if people would
prefer git for their personal repository, that's possible even if others
use mercurial.
http://mercurial.selenic.com/wiki/HgGit
If I can find some time for this, I will see what I can come up with,
but it may take a while for me to find time ;-)
/Simon
--
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
To unsubscribe, reply using "remove me" as the subject.
