Re: control toolbox - time delays

[Carnë Draug]

On 14 January 2013 22:31, Philip Nienhuis <address@hidden> wrote:
> Carnė Draug wrote:
>>
>> 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.
>
>
> Wouldn't know about the tarball, but AFAICS all the other stuff is a few
> clicks with TortoiseSVN (on Windows). And a tarball would be a simple "tar
> cvzf"

No. The thing is give someone, a normal user, a URL for the svn server
which is always for the last revision. Example:

Link for the latest revision of the cmpermute.m file is:
http://hg.savannah.gnu.org/hgweb/octave/file/default/scripts/image/cmpermute.m

Link for the latest revision on the stable branch of the cmpermute.m file is:
http://hg.savannah.gnu.org/hgweb/octave/file/stable/scripts/image/cmpermute.m

Link for a tarball of the whole octave repo, default branch
http://hg.savannah.gnu.org/hgweb/octave/archive/default.tar.gz

Link for a tarball of the whole octave repo, classdef branch
http://hg.savannah.gnu.org/hgweb/octave/archive/classdef.tar.gz

This is very useful. You can give a link and know that it will still
be up to date tomorrow. This functionality was present before with
svn.

>>> 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.
>
>
> I'm not against branching. I have a few local io package "branches" on my
> HD, much like you apparently have for the image package. But I don't need a
> VCS to keep them apart.
> I take it for granted that the image package is way more complicated than
> the io package.

The image package is not more complicated than io. But what we are
doing is quite sub optimal. With hg and git, these things are much
more natural.

> Anyway how does branching differ between SVN and Mercurial?

I started writing an explanation but got a bit long. I think a video
might be able to explain it quite well. See
http://www.youtube.com/watch?v=ACFZkByN9-U which shows how to do this
in windows with TortoiseHg. If you wish to keep doing what you are
already doing, you can do the first type of branching that he mentions
(branching from cloning) but that looks something specific to
TortoiseHG. The anonymous, which he shows at the end, are much more
common. But the link from Jordi http://hginit.com/00.html is quite
good.

"Mercurial separates the act of committing new code from the act of
inflicting it on everybody else."

Basically, you make commits local, creating as many heads/branches as
you want, and when one of them is ready, you can rebase it. What this
does, is turn all the changes from that head since it split with
another, into a single commit. And this one single commit, the one
that actually makes something work and is not half finished work, is
the one that you push to the central repository.
On 15 January 2013 22:38, Philip Nienhuis <address@hidden> wrote:
> Fixing the permissions for all those individual OF package (80+ nowadays?)
> repos will be quite a bit of work, unless all current OF devs get permission
> to push to any package. Is that the intention? Or would you rather have the
> package maintainers keep track of permissions for their packages?
>
> I haven't thought much about it, but at first sight I found nothing
> fundamentally wrong with the current situation (= any OF dev can commit to
> any package). Unless the number of OF devs gets out of control, of course,
> which OTOH can also be perceived as positive :-).

I think that the most active forge developers should have commit
access to all of the subrepos. Anyway, I should trim down the list
again, like we did some 2 years ago.

Carnë