Hi,

On Mon, 19 Mar 2007, Petr Baudis wrote:

quoted text
> 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

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html