Re: Breaks in lenny
Manoj Srivastava <srivasta@debian.org> writes:
> On Fri, 21 Dec 2007 14:04:29 -0800, Russ Allbery <rra@debian.org> said:
>> If people use branches the way that quilt manages patches, it's great,
>> and you get everything you need, provided that you can figure out their
>> branch and merge strategy (which is sometimes rather tricky). If they
>> use the VCS like most people use Subversion or the like, you get a
>> giant wad of patch, which is way less useful than what quilt gives you.
> This sounds more like a usage issue than a toolset issue.
> Of course, you could be argyuing that quilt somehow encourages better
> policies inherently, as opposed to a version control system, but I
> would have to see some data backing that claim befire I would entertain
> it.
Yes, that's basically what I'm arguing, but I'm not sure I have the data
to prove it either.
>> Yes, you could manage a giant wad of patch in quilt too, but people
>> tend not to. The workflow of quilt really pushes people into
>> maintaining separate patches per distinct change. The workflow for a
>> DVCS does not, which can be a bit of a problem.
> Err. I am not sure what you consider a work-flow for a
> distributed version control system like arch or git; but the common
> themes that have emerged on the pkg-vcs mailing list, and the the talks
> Martin and I gave at debconf, seems to indicate otherwise.
That's exactly the problem. It doesn't have a single workflow; it's a
general tool that you can use in many different ways, and you have to go
to talks and read papers and study supplemental information to figure out
how to do this in the way that works well.
quilt, on the other hand, essentially enforces this workflow, since it's
the only way in which quilt really works.
I would never do upstream development in quilt. It's horrible at being a
traditional VCS. But for what one does with Debian packaging, it's great.
>> Also, quilt trivially juggles forty, sixty, or a hundred patches. I'm
>> still a bit skeptical that a DVCS is going to handle that many branches
>> and integration points as trivially as quilt does what it does, but I'm
>> going to have to spend a fair number of hours playing with something
>> like git before I'll have an informed opinion.
>
> I think you just need to go look at the Linux kernel source, and
> git, and number and size of the different trees ythat are out there,
> and how well git scales to those.
Hm. This seems like a non sequitur to me. What is going on with the
Linux tree is radically different than what I do with a Debian package.
It's not really comparable; the workflow is completely different and in
some cases essentially reversed.
I need to be able to maintain a ton of small patches in an easily
separable form that often will never be merged upstream, while doing the
absolute minimum of work to pull those patches forward each time a new
upstream version is released and still keeping each change separate.
quilt does this perfectly. All explanations that I've seen so far on how
to do this with git or arch are more complicated and slower than my
workflow with quilt. With quilt, the typical upgrade is:
* import new upstream source (done in the underlying VCS)
* quilt push -a
* repeat for each failing patch until no patches fail:
- if quilt says patch was applied upstream, quilt delete the patch
- otherwise, quilt push -f <patch>, resolve conflicts, quilt refresh
* quilt pop -a
* commit results
The normal case is no work at all. I literally don't have to do a thing
except, if I choose, refresh patches that now have fuzz. The next most
common case is there will be a few patches that upstream took that quilt
will tell me are already applied and I just quilt delete them. Merging is
rare. A DVCS might be somewhat better at that part, although most merges
I run into are obvious to a human and impossible for a computer (variable
renamings, API changes that change the function calls in affected code,
that sort of thing).
I don't have to update any other branches. It's basically doing, under
the hood, pretty much what the DVCSes do, as I understand them, except
that rather than have my working object be a branch, my working object is
a patch. I LIKE that. I would much rather work on a patch than a branch
because a patch is much easier to understand and can't ever get into an
inconsistent state, and quilt lets me manipulate a patch in much the same
way as a branch when I need to (add files to it, remove files from it,
update with new changes, etc.).
There's no need to update metadata between branches. There's no need to
inform branches about what patches have been merged, or manipulate the VCS
metadata so that I can later merge branches without it trying to re-merge
chnages that weren't conceptually part of the work I was doing on that
branch.
Similarly, if there's something new I have to fix, the workflow is:
* quilt push -a (the branch switching equivalent)
* quilt new <patch> (the equivalent of creating a new branch)
* quilt edit <file>
* quilt refresh (the commit equivalent)
* quilt pop -a (the branch switching equivalent)
It's the same number of steps as the VCS approach, and it creates the
patch as an artifact so that I can easily review it without needing to run
other commands to create it.
If I were merging in multiple lines of development or patches from
hundreds of other people and resolving conflicts between them, the DVCS
advantages make a ton of sense, but that's not what I'm doing when I'm
maintaining the average Debian package.
> Where are we going with this (very interesting) discussion,
> anyway? I seem to have lost track of the big picture road map/
I'm continuing to object to adding wording to Policy that discourages
people from using patch systems such as quilt or dpatch -- that's where
this all started.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: