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

[Benja Fallenstein]

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. 

Why?

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