[Monotone-devel] use case

[Tom Tromey]

Graydon --

I've thought a little bit about support the libgcj/classpath use case.
I'm wondering if you've thought about it too, now that you've
experienced it first hand?

For those not in the know, libgcj and classpath share a lot of source
code.  However, in the gcc tree (where libgcj resides), files appear
in different directories.  E.g., the Object file is
"gcc/libjava/java/lang/Object.java" in libgcj, but
"classpath/java/lang/Object.java" in classpath.

The ideal situation would be that if somebody writes a Classpath
change, and we like it for libgcj, a libgcj could simply sign it and
it would appear in the libgcj tree.  Even more ideally, the same could
be done for changes to files that have a required divergence --
monotone would try to merge the changes into the destination tree.

I'm not sure that is possible, due to the renaming involved.  But
since I'm sure I don't understand monotone well enough, I don't really
trust that conclusion.

I didn't see any info in the FAQ or the manual about renaming files.
It seems to me that for monotone to recognize a rename, you'd have to
do a rename as a separate commit, before making any changes to the
renamed file.  But this turns out to be an unusual approach... for
instance, in Java it may result in an unbuildable tree (if you are
refactoring).


One idea for the classpath scenario would be to change the build set
up a bit.  We could have a directory, gcc/classpath, which is a branch
of the classpath repository (checked out in the gcc source tree).
That way we wouldn't have to worry about the renaming problem.


This situation is actually not that uncommon.  For instance, in gcc we
incorporate several upstream sources: classpath, zlib, fastjar, and
the org.w3c.* classes in libgcj.  An OS distribution is basically
nothing but taking upstream sources and adding a few local changes...

Tom