public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: [ANNOUNCEMENT] Updated: rebase-4.1.0-1
Date: Tue, 27 Mar 2012 08:37:00 -0000	[thread overview]
Message-ID: <20120327083621.GA30721@calimero.vinschen.de> (raw)
In-Reply-To: <4F712CFC.9050603@cs.utoronto.ca>

On Mar 26 22:59, Ryan Johnson wrote:
> On 26/03/2012 9:40 PM, Jason Tishler wrote:
> >New News:
> >=== ====
> >I have updated the version of rebase to 4.1.0-1.  The tarballs should be
> >available on a Cygwin mirror near you shortly.
> >
> >The following are the changes since the previous release:
> >
> >     * Add rebase/rebaseall touch file (i.e., -t option) support.
> >
> >     * Add rebaseall setup (i.e., -p option) support.
> >
> >     * Add .oct to the default rebaseall suffix list.
> I've been meaning to ask... but maybe the above-mentioned -p flag
> obsoletes it now: What's the most efficient way to rebase after
> running setup? We've had the rebase db for a while now, so running
> rebaseall seems like overkill. Only the newly downloaded dlls need

Now that the new rebase is out, I'm going to create an _autorebase
package which will automatically call rebaseall at the end of a
successful run of setup, if that run also updated existing DLLs or
came with new DLLs.

In some cases this might take two minutes or so at the end of a setup
run, but at least we should see less rebase problems in future.

The most efficient way would be to change rebaseall so that only
DLLs are given to rebase which are updated or new.  But rebaseall
would still have to search the files in /etc/setup.  And rebase
still opens every DLL in the DB and from the command line to see
if the DB and reality are still in sync, and to decide which DLLs
have to be rebased and which are not.  So I'm not sure you can
make it much faster, unless you make the algorithm in rebase itself
faster.  You're welcome to send patches to the cygwin-apps list.
I'm pretty sure there is room for improvement.

Needless to say that the ultimately most efficient way would be
to find a method to avoid rebase problems after fork at all.  The
last attempt at it looked promising at first, but then again...
http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/afdf1b68-1f3e-47f5-94cf-51e397afe073


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

  reply	other threads:[~2012-03-27  8:37 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-27  1:44 Jason Tishler
2012-03-27  2:59 ` Ryan Johnson
2012-03-27  8:37   ` Corinna Vinschen [this message]
2012-03-27 11:41     ` Michael Lutz
2012-03-27 14:07       ` Ryan Johnson
2012-03-27 15:19     ` Ryan Johnson
2012-03-27 15:29       ` Corinna Vinschen
2012-03-27 15:58         ` Ryan Johnson
2012-03-27 16:10         ` Karl M
2012-03-27 16:15           ` Corinna Vinschen
2012-03-27 16:35             ` Karl M
2012-03-27 17:13               ` Christopher Faylor
2012-03-27 17:17               ` Corinna Vinschen
2012-03-27 18:02                 ` Ken Brown
2012-03-27 18:21                   ` Corinna Vinschen
2012-03-27 18:32                     ` Ken Brown
2012-03-27 18:49                       ` Corinna Vinschen
2012-03-27 19:13                         ` Ken Brown
2012-03-27 20:47                           ` Corinna Vinschen
2012-03-27 21:52                             ` Ken Brown
2012-03-27 19:11                 ` Karl M
2012-03-27 23:28     ` JonY
2012-03-28  7:34       ` Corinna Vinschen
2012-03-28 10:39         ` JonY
2012-03-28 12:10           ` Corinna Vinschen
2012-03-28 12:21             ` JonY
2012-03-28 19:43           ` Christopher Faylor
2012-03-28 20:22             ` Brian Wilson
2012-03-28 22:43               ` JonY
2012-03-29  3:01                 ` Ryan Johnson
2012-03-29  5:52                   ` Christopher Faylor
2012-04-26  8:50     ` KJ
2012-04-26 19:47       ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120327083621.GA30721@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).