Re: RFC: Central version control for Debian
>>>>> "Matt" == Matt Zimmerman <firstname.lastname@example.org> writes:
Matt> Both. And in one place.
Oh well... Perhaps you experience has varied, but I always I found it
difficult tracking anything except upstream code with CVS.
Consider, for instance:
1. import upstream source version 1.
2. make change A to fix bug#1.
3. make change B to fix bug#2.
4. make change C to fix bug#3.
5. import upstream source version 2, only change B is in this code.
6. merge changes A and C into new source.
7. bug #1 was not fixed correctly with change A. Fix with change D.
8. import upstream source version 3.
9. merge changes A, C, and D into new source.
11. bug #1 was still not fixed correctly with changes A+D. Fix with change E.
12. make change F to fix bug#4.
(note there are good reasons why upstream has decided not to merge in
your changes, for instance they might be Debian specific, or they
might not like your fix for some reason).
Now, how do you possibly:
- determine that change C was made in step 3, and the same change was
re-applied to the new versions?
- determine that change A was incomplete by itself without changes D
- isolate the patch required for A,D,E (and any subsequent patches),
to mail upstream (without patch for change C or F, as you don't want
to confuse the issue)?
(good log messages might help here, but might be confusing when more
This sample might be easy, I have seen more complicated situations
though. Assume for instance that each change requires updating
autoconf and automake stuff, and that this stuff needs to be stored in
CVS (eg. heimdal requires CVS versions of these tools). Now how do you
isolate the above changes without getting pages of irrelevant
autotools generated diffs?
True, perhaps I wasn't using CVS to its maximum efficiency, but I couldn't
see how to do it any better.
(I hope I haven't made any obvious mistakes here <grin> )
Brian May <email@example.com>