Re: control toolbox - time delays

[Lukas Reichlin]

On 15.01.2013, at 18:38, Jordi Gutiérrez Hermoso <address@hidden> wrote:

> On 14 January 2013 17:31, Philip Nienhuis <address@hidden> wrote:
>> Anyway how does branching differ between SVN and Mercurial?
> 
> The biggest difference is that merging *works* in hg:
> 
>    http://hginit.com/00.html
> 
> Briefly, if you branch off trunk to featureX in svn, and you
> frequently merge trunk into featureX, when you're ready to merge
> featureX back into trunk in svn, you have to treat every difference
> between featureX and trunk as a conflict in the merge. In hg, this is
> actually a trivial operation from the user point of view.
> 
>> If you guys move octave-forge to hg, I hope that I do not have to
>> clone and/or update the entire repo, but only the package I maintain
>> (io).
> 
> No, as I said before, the idea is one repo per OF package. I'm not
> sure exactly what to do about some of the OF code that is not inside
> any package, but it doesn't seem like anyone cares about that, except
> for the webpages.
> 
>> If I need to e.g., rebase my csets because meanwhile something was
>> updated in some other package, I think I'll give up maintaining io.
> 
> Rebasing and/or merges are a fact of life when working with other
> people, regardless of the VCS. If you had to work together with
> someone else regularly on an svn project (i.e. same directory), you
> would soon see similar problems or worse to what you've experienced
> with hg. If you mostly work by yourself on the io package and only
> occasionally someone else happens to be giving you patches, you should
> not face any serious problems with hg doing rebases or merges.
> 
> - Jordi G. H.

Hi Jordi

I've just completed reading hginit and it was fun to read! IMHO HG just feels 
right :-) Could you please do the move from SVN to HG ASAP? AFAIK, Thomas works 
on control-2.4.1 instead of the latest SVN revision and I fear that we get a 
big mess if we don't move to HG very soon.

If I understood hginit correctly, I think we should do the following:

Convert the control repository at SourceForge from SVN to HG (hmm, is it 
possible to keep the old SVN revisions as HG changesets?)

Then we clone this repository to create a delay branch and host it somewhere 
(where?!)

Thomas pulls from the delay branch repository, commits his work by the spoonful 
to his working copy and pushes them to the delay repository from time to time.

When delay is ready, we merge the changesets from delay to the control 
repository on SourceForge

Lukas