From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Petr Baudis <pasky@suse.cz>
Cc: Rocco Rutte <pdmef@gmx.net>, git@vger.kernel.org
Subject: Re: Libification project (SoC)
Date: Mon, 19 Mar 2007 02:43:54 +0100 (CET) [thread overview]
Message-ID: <Pine.LNX.4.63.0703190235330.22628@wbgn013.biozentrum.uni-wuerzburg.de> (raw)
In-Reply-To: <20070319012111.GS18276@pasky.or.cz>
Hi,
On Mon, 19 Mar 2007, Petr Baudis wrote:
> On Mon, Mar 19, 2007 at 12:48:27AM CET, Johannes Schindelin wrote:
> > On Sun, 18 Mar 2007, Petr Baudis wrote:
> >
> > > [...] if you look at the UNIX history, you'll notice that first
> > > people started with non-reentrant stuff because it was "good enough"
> > > and then came back later and added reentrant versions anyway. Let's
> > > learn from history. It's question of probability but it's very
> > > likely this will happen to us as well.
> >
> > Yes, let's learn from history. Start with a libgit that is good
> > enough. And when somebody actually needs it to behave a little
> > differently, or more sophisticated, then let that somebody work on it!
>
> I was talking about the API. The API has to be designed to be
> reentrant. And you get pretty much stuck with the API. And requiring
> reentrance isn't that far off once libgit is there, as I tried to point
> out; it's not really any obscure requirement.
I don't see _any_ problem in making an API which works with _one_ repo
first. This has several advantages:
- most users (if any!) will work that way,
- it is easier to implement,
- you are more likely to get that right than the more complex thing you
seem to want already in the first version, and
- it is easy enough to extend the API later, _retaining_ the small and
beautiful functions.
As for the memory problems I was pointing out to you on IRC: if you do
some operation on one repo, and run out of memory, okay, there is not much
you can do about it. Tough luck.
If you cache different repos in the _same_ process, and run out of memory,
you should free the caches of the _other_ repos first, instead of just
erroring out. This is not entirely trivial, likely to make libgit fragile,
and quite possibly a performance hit (making libgit unattractive for
plumbing, which would take away the best test case for libgit).
Also, when you cache different repos, you want to avoid duplicating
identical objects in different caches, which makes the cache handling no
easier.
But even if these issues would not exist, isn't it obvious that you should
start with something _simple_?
Ciao,
Dscho
next prev parent reply other threads:[~2007-03-19 1:44 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-16 4:24 Libification project (SoC) Luiz Fernando N. Capitulino
2007-03-16 4:59 ` Shawn O. Pearce
2007-03-16 5:30 ` Junio C Hamano
2007-03-16 6:00 ` Shawn O. Pearce
2007-03-16 6:54 ` Junio C Hamano
2007-03-16 11:54 ` Johannes Schindelin
2007-03-16 13:09 ` Rocco Rutte
2007-03-16 15:12 ` Johannes Schindelin
2007-03-16 15:55 ` Nicolas Pitre
2007-03-16 16:13 ` Johannes Schindelin
2007-03-16 16:26 ` Nicolas Pitre
2007-03-16 18:22 ` Steve Frécinaux
2007-03-16 18:53 ` Nicolas Pitre
2007-03-18 13:57 ` Petr Baudis
2007-03-16 23:26 ` Johannes Schindelin
2007-03-16 16:17 ` Shawn O. Pearce
2007-03-16 18:20 ` Marco Costalba
2007-03-16 18:38 ` Marco Costalba
2007-03-16 18:59 ` Nicolas Pitre
2007-03-16 21:07 ` Marco Costalba
2007-03-16 23:24 ` Johannes Schindelin
2007-03-17 7:04 ` Marco Costalba
2007-03-17 17:29 ` Johannes Schindelin
2007-03-16 19:09 ` Andy Parkins
2007-03-18 14:08 ` Petr Baudis
2007-03-18 23:48 ` Johannes Schindelin
2007-03-19 1:21 ` Petr Baudis
2007-03-19 1:43 ` Johannes Schindelin [this message]
2007-03-19 2:56 ` Theodore Tso
2007-03-19 3:55 ` Shawn O. Pearce
2007-03-19 14:57 ` Johannes Schindelin
2007-03-19 16:28 ` Linus Torvalds
2007-03-19 16:32 ` Linus Torvalds
2007-03-21 11:17 ` Andreas Ericsson
2007-03-21 17:24 ` Linus Torvalds
2007-03-22 9:51 ` Andreas Ericsson
2007-03-19 7:01 ` Marco Costalba
2007-03-19 9:46 ` Steve Frécinaux
2007-03-19 10:33 ` Steve Frécinaux
2007-03-19 12:37 ` Johannes Schindelin
2007-03-19 12:52 ` Petr Baudis
2007-03-19 13:55 ` Johannes Schindelin
2007-03-19 13:04 ` Marco Costalba
2007-03-16 12:53 ` Petr Baudis
2007-03-16 13:47 ` Luiz Fernando N. Capitulino
2007-03-16 14:08 ` Petr Baudis
2007-03-16 18:38 ` Luiz Fernando N. Capitulino
2007-03-16 23:16 ` Shawn O. Pearce
2007-03-17 19:58 ` Luiz Fernando N. Capitulino
2007-03-18 5:23 ` Shawn O. Pearce
2007-03-18 5:52 ` Junio C Hamano
2007-03-18 16:18 ` Luiz Fernando N. Capitulino
2007-03-18 19:31 ` Junio C Hamano
2007-03-19 16:09 ` Luiz Fernando N. Capitulino
2007-03-18 21:15 ` Nicolas Pitre
2007-03-16 15:16 ` Johannes Schindelin
2007-03-16 8:06 ` Johannes Sixt
2007-03-16 8:58 ` Matthieu Moy
2007-03-16 11:51 ` Johannes Schindelin
2007-03-16 12:55 ` Petr Baudis
2007-03-17 2:24 ` Jakub Narebski
2007-03-17 5:22 ` Shawn O. Pearce
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.63.0703190235330.22628@wbgn013.biozentrum.uni-wuerzburg.de \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=pasky@suse.cz \
--cc=pdmef@gmx.net \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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).