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.