[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fenfire-dev] 7 projects to one big branch?

From: Benja Fallenstein
Subject: Re: [Fenfire-dev] 7 projects to one big branch?
Date: Fri, 16 Jul 2004 13:46:37 +0200
User-agent: Mozilla Thunderbird 0.7.1 (X11/20040708)

Janne Kujala wrote:
On Fri, Jul 16, 2004 at 12:18:19AM +0200, Benja Fallenstein wrote:
For example, it's not so uncommon to create a new vob because I need it in Loom code. If I can make it generic, i.e. not dependent on Loom, it would be wrong to put it Loom; it should be in Libvob. But I obviously need to change Loom also, to use the new vob.

Perhaps you should first implement the new vob in Libvob,
write tests, debug it, and only then use it in Loom.


I prefer coding being driven by actual needs, rather than creating interfaces and classes &c in thin air and later discovering that they don't actually do what is needed. It's more fun, too. And that's important, too :-)

Or you could implement it just for the specific need, put it in Loom, and generalize when it is needed somewhere else.

Well, with that logic, all of Libvob could be in the Fenfire project, because it's not used anywhere except in Fenfire at the moment. The point is to make it *possible* to use it independently.

I think it would be wrong to try to change this style of development. I can live with maintaining the status quo and not putting the projects in a single branch, but being forced not to add features to Libvob or Fenfire when I need them in Loom would seem just silly, encouraging bad code when we need better code.

There's no problem in adding new features; they (usually) do not
break anything.

I don't think that there's a problem with changing existing interfaces to make them better, either, as long as the code using it is updated so that it continues to work.

But the question was whether commits should be atomic, not sure what this has to do with it.

Also, about the "atomic commits": say I want to roll back a few versions. If I made a change to both Loom and Fenfire, I need to find the matching versions so that everything will compile. If I have only one branch, I get the versions of Loom and Fenfire that work together.

Adding new features does not prevent rolling back the dependent project.

The usual scenario is that you want to undo a change done in the last few days, either because you don't like it or because it introduced a bug. In both cases, you would usually want to roll back both projects, I'd think.

The situation I meant is that if I do a single change, like changing the RDF writer in Fenfire and changing Loom to use the new interface, then it would be more useful to have these two in one diff, because it's one change.

This is the one important point.
How often are non backward compatible changes needed?

I was not necessarily talking about a backward incompatible change, where you interpreting something into this?

However, backward incompatible changes may be needed when refactoring bad interfaces into better ones. Our code is not good or stable enough that it doesn't need this, in my opinion.

The only version control problems I ever had were caused by someone changing some interface and not making the
corresponding changes to every place where it was used.

That means that those changes need to be made, not that bad interfaces shouldn't be refactored, at least in the current state of things, IMO.

If some feature is not stable enough for others to use, it can just as well be implemented in the project for which it is being developed.

I don't agree, because NONE of our code is stable enough that we can guarantee that code depending on it doens't need to be changed. Our code *can* be used by code that *can* be changed when our code changes, of course.

- Benja

reply via email to

[Prev in Thread] Current Thread [Next in Thread]