git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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

  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).