octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Merging new audio functionality into Octave


From: Jordi Gutiérrez Hermoso
Subject: Re: Merging new audio functionality into Octave
Date: Wed, 02 Oct 2013 16:32:52 -0400

On Wed, 2013-10-02 at 13:50 -0400, John W. Eaton wrote:
> On 10/02/2013 09:40 AM, Mike Miller wrote:
> 
> > I have gone ahead and made most of these changes, ready for review.
> > Pull into a new or existing clone of Octave with
> >
> >    hg pull https://bitbucket.org/mtmiller/octave-audio-gsoc
> 
> When I clone, I get
> 
>    coredump:206> hg clone https://bitbucket.org/mtmiller/octave-audio-gsoc
>    destination directory: octave-audio-gsoc
>    requesting all changes
>    adding changesets
>    adding manifests
>    adding file changes
>    added 17577 changesets with 107458 changes to 12197 files (+1 heads)
>    updating to bookmark @
>    cloning subrepo gnulib-hg from 
> https://bitbucket.org/mtmiller/octave-audio-gsoc/gnulib-hg
>    requesting all changes
>    adding changesets
>    adding manifests
>    adding file changes
>    added 17577 changesets with 107458 changes to 12197 files (+1 heads)
>    abort: unknown revision '6057744acd2c71c069a4b171c5fe1ff0d86c9e5f'!
> 
> What's that last abort message about?

Ugh, subrepos. The abort happens when hg is trying to update the
subrepo to a revision that doesn't exist. Looks like the gnulib-hg in
there is missing a revision, so when hg tries to update to a superrepo
revision that's referring to that subrepo revision, it aborts.

Go into the subrepo, pull from Savannah, and then go into the
superrepo and update again.

I really wish we could fix this subrepo mess once and for all. It's a
bit better than it was with the subrepo forever tied to some central
git location, but still not great.

- Jordi G. H.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]