Re: control toolbox - time delays

[Carnë Draug]

On 10 January 2013 20:24, Philip Nienhuis <address@hidden> wrote:
> The sourceforge web interface is by no means the only way to to deal with
> octave-forge. There are various VCS clients (graphical or CLI) that simply
> bypass the SF mess.

That all requires to have a checkout of the repository too. Not nice.
And doesn't allow me to give someone a URL for the latest revision of
a file, or that downloads a tarball with the latest revision of a
package.

> As to OF, I wonder what problem would be solved with Mercurial.
> Currently there is little or no simultaneous access to code in the repo,
> most packages are maintained by individuals.
> As to branches, the control package -as suggested- would be the first.
> Perhaps a temporary io branch as well, to support the new core Java
> interface next to the Java-package based one for older Octave versions.

Branches are useful, even when there's only 1 person working on a
package. The implementation of the strel in the image package a few
weeks ago was a case where that would be useful. It would also mean I
could do a 2.0.1 release of the image package now (since there's
enough changes for that) but because of how strel is being placed into
the other functions, I need to wait until things are complete which
may take a lot of time and then I'll do a 2.2.0 (something like
default and stable branches on core).

And another useful thing are local commits and the possibility to
ammend them or rebase. I can't be the only person that starts doing
something, needs to stop before being ready for commit, and starts
working on something else. With mercurial, I could make a commit with
those half changes, not push them, and work on the other head. This is
actually the same as doing a branch but no copying things around. I
have a lot checkouts of the image repository around with such half
things.

> Has anybody checked to see if SourceForge's mercurial support doesn't suck
> as much as its svn support?

I was looking for projects in sourceforge that use mercurial but they
all seem to have the actual repository hosted somewhere else or have
not upgraded (in which case they had hgweb). But scribus has upgraded
and they are using git. Their web interface is exactly the same as we
have for svn http://sourceforge.net/p/scribus/code/ so my guess is
that sourceforge uses it for all projects independent of the VCS being
used, and changing to mercurial will not fix the web interface issue.

Carnë