>>>>> "Jan" == Jan Setje-Eilers <setje at smack.Eng.Sun.COM> writes:
Jan> I don't think anyone was suggesting allowing actually multiple
Jan> deltas. The case in which we might have considered talking about an
Jan> exception would have involved a create (so no pre-existing gate
Jan> rev), in essence introducing one bit of external history from the
Jan> beginning.
Okay, I misunderstood the suggestion. But then it seems like merging
with upstream gets harder over time, since the only baseline
("ancestor") file in the repository is the first one. Even if local
changes are propagated upstream, I'm not aware of any merging tools that
make it easy to skip over those changes, so that you only see the latest
ones (i.e., the ones that are interesting). So, as you say, it would
cease to be useful after awhile.
The other options that I've seen so far (unless I missed one in the
flood of email) are:
1. keep diffs between the ON source and the upstream source in the ON
tree (the project team's current proposal).
2. keep diffs between the ON source and the upstream source somewhere
else, probably the project web space on opensolaris.org.
3. keep a snapshot of the upstream source somewhere else (again,
probably the project web space)
I'd reject 2 off the top. Keeping the diffs separate makes it much more
likely that they will get out-of-date.
Choice 3 seems okay; it's better than choice 2 in that the snapshot does
not become stale if additional local changes are made. Updates from
upstream could be handled with a 3-way merge tool; or by generating
diffs between ON and the snapshot, and applying those to the upstream
version.
I don't have a problem with 1, though I'm aware that others do. While I
can sort of see their point, I don't understand why this seems to be a
must-fix item. Yes, the diffs have to be manually maintained. But so
do READMEs, and those seem to be okay (there are over 100 of them in the
gate).
mike
