On Fri, 21 Dec 2007 14:04:29 -0800, Russ Allbery <[EMAIL PROTECTED]> said:
> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>> I am not sure I follow. When you unpack a .dsc based on an
>> integration branch of a DVCS based package, you have the sources that
>> are going to be fed to the compiler -- no additional work is required
>> by the end user.
>>
>> The adopter gets a set of branches, all named, with aproper history,
>> changelogs, and best of all, something that can compile independently
>> of all the other branches of development in the integration branch.
> 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.
It seems to me that the concept of Feature branches + sloppy
branch + integration branch offers a clkeaner, easier to update, and
cherry pick patches, than does quilt, what with the global ordering
required for patches; whereas feature branches can just replay new
changes without having to deal with problems that were solved once
earlier. In other words, I am not convinced that quilt, as a tool is
better practice than feature branches are.
> 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.
As you said, anyone can hack a bad work-flow using any tool.
> 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.
quilt is not even in the ball park. I am not sure it can play
the same ball game, even. I would love to see anyone try to convince
Linus how quilt would make the kernel code easier to deal with than git
does (advance notice so I can bring pop corn would be appreciated).
> Plus, quilt is WAY easier to understand than any DVCS that I've ever
> seen. I'm still at the point in the learning curve where that's
> fairly significant. :/
Having had to work with quilt, and having also worked with arch,
bzr, darcs, and git, I think working with any of the DVCS's is less
frustrating than working with a set of .patch files and quilt.
Where are we going with this (very interesting) discussion,
anyway? I seem to have lost track of the big picture road map/
manoj
--
Any sufficiently advanced bug is indistinguishable from a feature. Rich
Kulawiec
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
