Manoj Srivastava <[EMAIL PROTECTED]> writes: > On Fri, 21 Dec 2007 14:04:29 -0800, Russ Allbery <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
