[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 00:18:19 +0200
User-agent: Mozilla Thunderbird 0.7.1 (X11/20040708)


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.


- Benja

reply via email to

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