patch series does not make VCS obsolete

[Manoj Srivastava]

On Wed, Oct 01 2008, martin f krafft wrote:

> also sprach Manoj Srivastava <srivasta at acm.org> [2008.10.01.0302 +0200]:
>>         Only if you like working with patch series, and prefer to lose
>>  all the information that the original VCS contained. I prefer to see
>>  the whole history, not just a snapshot, when I am joining a development
>>  effort. 
>
> Manoj, please stop seeing things black and white. By providing
> a patch series in the source package, you are not "losing all the
> information that the original VCS contained", as the original VCS
> will still be around and will serve up all the history to those who
> want it.

        You have snipped context. What  you quote is me replying to a
 mail that I interpreted as saying that the patch series was preferred,
 which by your own admission above it is not.

> All that's happening is that the changes between upstream and what
> is packaged for Debian aren't merged and dumped into one, gigantic,
> monolithic diff, from which it's not exactly easy to extract single
> features. Instead, separate features are kept in separate patches,
> and a series file tells anyone, not just quilt, in what order the
> patches should be applied.
>
> This
>
>   - makes it a lot easier for everyone to extract features from the
>     source package;
>   - still allows people to create monolithic patches over the whole source
>     package, because "debian/rules patch" will prepare the source
>     tree accordingly, and the v3 quilt format will even make that
>     unnecessary;
>   - still allows you to keep using your treasured VCS
>   - still allows everyone to inspect the history in your VCS, or use
>     it instead of the source package.

        As far as I can tell, so far, I have to change my work-flow for
 this to happen in the following way: 
   The build branch which is to be included in the source package is now
   identical with the upstream branch, modulo ./debian. Currently, I
   test, and ship, the integration branch. I don't really go through a
   .dsc stage; I just make changes to the branches, sync the
   integration branch, and cp the result over to the virtual machine.

   In the new method, I'll have to let tg create an integration branch,
   create stacked patches, commit to  ./debian, commit the new submodule
   to the build branch, then copy.

   I also do not like there being two branches which are almost
   identical, upstream and build, but that is a personal
   idiosyncrasy. But this whole serialization of patches thing still
   feels like a kluge.

        The kluge is doable, I suppose. But not yet compelling.

        manoj
-- 
I doubt, therefore I might be.
Manoj Srivastava <srivasta at acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C