On Tue, Mar 20, 2012 at 04:39:10PM -0400, Jordi Gutiérrez Hermoso wrote:
> 2012/3/20 Thomas Weber <twe...@debian.org>:
> > On Tue, Mar 20, 2012 at 12:41:43AM -0400, Jordi Gutiérrez Hermoso wrote:
> >> Please consider hg, as it is what Octave core uses, and if we're
> >> moving OF to a DVCS, it would be best to consolidate the two projects.
> >
> > What's the advantage? Where precisely is octave-forge better off
> > with a DVCS?
>
> I don't know, why did you stop using svn for Debian packages? Same
> situation.
Eh, no. The difference between git and svn in Debian packaging is not so
much about the VCS, but about the distribution-specific tools around
them. In theory, we could switch to hg. In practice, git-buildpackage is
far better than hg-buildpackage. This is not a VCS question, but simply
one of the surrounding machinery.
BTW, the most compelling reason for me for the current workflow is that
I only need one command to get both the Debian packaging code and the
code from octave/octave-forge. This again has nothing to do with the
used VCS, but with pristine-tar.
> > I keep on wondering what the used VCS has to do with that. If I want
> > a tarball of the current version, I run 'svn update' and have the
> > latest sources, just like with 'hg pull' or 'git pull'. Everything
> > else is totally independent of the VCS.
>
> But the tarball *shouldn't* exist independently of Octave.
You have a narrow view of octave development. Have you looked at
Dynare, Shogun, Cantor, etc.? Should they now all move to octave-forge
packages?
If you cannot develop and release software independently of Octave,
then indeed, there is a problem.
> right now for example is that Octave-Forge packages are developed
> independently of Octave. On several occasions developers have shied
> away from using newer Octave features because, e.g. Debian is
> packaging older Octave versions. Such is the situation with fstat and
> zscore in the statistics package. If there could be two concurrent
> versions, with, say, DVCS branches, we could keep stable and current
> versions of OF packages to match Octave.
Like it or not, Octave is reaching a point where changing the API will
break lots of stuff, quite some of it outside octave-forge's realm.
> Also, if both are using the same DVCS, hg subrepos would be very
> helpful. They're fairly transparent. git submodules are a
> corresponding nightmare, and this isn't just me talking.
>
> > Do you want to use a separate repo for every package? Like 100 hg
> > repositories?
>
> Sure, why, do you want to drop the corresponding 100 git repos from
> Debian?
No, we use tarballs. I don't care what version control is used, even
none at all is fine (epstk is a package where I have no idea what
version control is used, for example).
> There really isn't much of a difference between 100 hg subrepos or 100
> svn subdirectories.
Yes, there is. Just having to type "hg clone xyz" 10 times is a pain, as
I'm currently learning with Debian on my machine (I don't have all
repositories here, the machine is only a few months old).
> > Have you considered what managing developer access to such
> > a number of repositories means?
>
> It's one server, no matter how many repos there are. It hasn't been a
> nightmare for Debian packages.
I disagree. Just type "hg clone xyz" 10 times in a row and replace xyz
with the package name - then come back. You will end up with a script
for cloning these repositores and another script for pulling them.
Repository-wide replacements for API changes are also far more work, as
you need individual commits for them.
> > The problem with testing OF packages has one simple solution -
> > enable pkg.m to do it.
>
> I want a unified build method that builds Octave and then builds and
> tests all OF packages against the same Octave build that just
> happened. Having consistent tools across this would be helpful.
This talk is leading nowhere. Just go ahead and implement it. The SVN
repository can be synced via rsync, so you can do it on your machine
without hammering the SF server.
Then push the repositories at some place and start adding some
developers.
Thomas
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Octave-dev mailing list
Octave-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/octave-dev
