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

[Janne Kujala]

On Fri, Jul 16, 2004 at 12:18:19AM +0200, Benja Fallenstein wrote:
> Matti Katila wrote:
> >- commits are atomic (I often change things in two projects 
> >  which depend on each other)
> >
> >   * That's not true. The projects not depend on each other. fenfire or 
> >     loom may depend them all but for example storm does depend none.
> >     If they depend on each other the design is broken already.
> 
> Well, it's true that they don't depend on *each other*, in the sense 
> that A depends on B and B depends on A. My sentence was wrong.
> 
> What I meant is that I change things in two projects, one of which 
> depends on the other. Mostly this happens with Loom/Libvob, 
> Fenfire/Libvob, or Loom/Fenfire, but it can also happen with Alph/Storm 
> or Loom/Alph.
> 
> 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. 
Or you could implement it just for the specific need, put it 
in Loom, and generalize when it is needed somewhere else.

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

> 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 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?

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