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? And not some hypothetical "xyz will be more involved if we just do
abc", some real, hard numbers, please.
The VCS is not a problem for octave-forge. Stop the bike-shedding.
> I am starting to formulate plans in my head for doing something like
> automatically rebuilding and testing OF packages against development
> versions of Octave so we can catch bugs earlier, and it would help if
> OF stopped using svn, e.g. by using hg subrepos.
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.
Do you want to use a separate repo for every package? Like 100 hg
repositories? Have you considered what managing developer access to such
a number of repositories means?
The problem with testing OF packages has one simple solution - enable
pkg.m to do it. Or ditch it entirely and switch to a
./configure | cmake
make
make check
workflow.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/octave-dev
