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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html