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

[Benja Fallenstein]

Hi,

sorry for the late answer. BTW, it would be six projects for now: 
callgl, navidoc, libvob, storm, alph, and fenfire; plus depends/, which 
isn't really a project. loom wouldn't be in there because of the legal 
issues for now. The idea would be to put it in when it is released, 
though, so it *is* seven projects in the long term.

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.

As another example, when I added the "save" command to Loom, Fenfire 
didn't have satisfactory support for saving an RDF graph (it didn't 
allow me to specify the namespaces to use, IIRC). So I had to change 
Fenfire. It would have been wrong to write a new RDF writer in Loom, 
because this is a general facility that should be in Fenfire (with Swamp).

>    * Another point of view (=software developement), long living 
>      interfaces matter much more than a single implementation issue.
>      From this point of view there can't be atomic commits between 
>      different projects.

I don't agree regarding Fenfire at this point in time, because none of 
our projects are really feature-complete enough for the other projects 
to use them through a stable interface. I mean, I don't have the time or 
wisdom to make Libvob perfect without writing any applications using it, 
before starting to use it in Loom or FenEdit. In particular FenEdit was 
written to test out the experimental Lob framework while writing it. 
However, because FenEdit depends on Alph it needs to be in Fenfire, so 
while working on FenEdit and lobs, I need to change both projects at the 
same time.

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.

> - you can diff all the projects at the same time
>
>    * I want to raise a question: "how many projects do you change at the 
>      same time?"

Normally, one or two. For examples of when I change two, see above :)

>      I don't want to diff all projects at the same time. It 
>      would be a mess.

Well, you have a point in that if you diff a number of different patches 
at the same time, then this could make things worse. For example, if I 
do a number of changes on my own branch (e.g. when I'm away like last 
weekend), then merge them into the main branch, and I've done different 
changes to the different projects, the commit would be even more of a 
mess...

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.

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.

> - you can have a makefile that compiles the Java code of 
>   all projects (also useful when changing > 1 project)
>
>    * We can have that Makefile without having everything in the same 
>      project.

True. (If we want to have it in the ff/ directory that contains the 
different projects, we'll need an eighth 'ff' project, though ;))

> - it's easier to check out everything (I read somewhere 
>   somebody complaining that you need to check out all those different 
>   projects to build fenfire)
>
>    * Not the strongest issue since only few (=mainly me and Benja) would 
>      make changes to every other projects. New developers may get a 
>      branch of a project when they find a bug and fix it.

True, maybe.

>    * buildcfg+scripts can be used to build fenfire.

To quote you: I like simple things. ;-) I don't find buildcfg or scripts 
simple -- it's one more thing to understand, rather than one thing less.

>    * Not an issue if everyone uses the main line as a developement branch 
>      as in cvs.

From here, it's too slow for that. :-(

(Note that the above is about branching, not about checking out everything.)

> - it's easier to branch to do your own development, you 
>   just need to make one branch, and you don't have this-project-is-branched and 
>   this-project-is-not so you must not commit to the second project 
>   without branching because you would commit to the mirror  
>
>    * you don't need to have a mirror.

Well, if you don't have write access, you just get a different error 
message and have less fixup problems than if you commit to the mirror.

I think if you're a developer with write access actually you can't have 
a mirror, because then you couldn't commit to the repository itself :-( 
-- at least not if you checked out the branch from the mirror (the 
speedup from that would be the reason to have a mirror, for me).

> - you can update all projects at the same time
>
>    * can be done with scripts.

Again, this makes things more difficult, rather than simpler--

>      It may be faster to update two 
>      smaller projects than one big.

--and probably slower, too: I would want to update all projects, not 
just one or two.

> I don't agree that putting all projects into one huge project would make 
> things easier, faster or cleaner.

Well, I think you probably understand my arguments now (if not speak up 
;-)), so if I can't convince you, we'll have to stay with the current 
way of doing things.

> Also, I want to hear Janne's comments as 
> well.

Janne?

- Benja