Re: cdbs?? Why?
Eddy PetriÅ?or wrote:
>> IMO, a SCM (source code managment system) is a tool to manage a line of
>> development (let's call that 'branch'), and you can get from each step
>> (let's call this 'revisions') to another by applying patches.
>>
>> svn does a pretty good job doing this, and personally, I think it is the
>> best central SCM I've seen so far [1]. You can create, apply and
>> review patches directly in SVN. Why should we duplicate this use case by
>> managing patches with another SCM (may it be dpatch or custom patch
>> helper scripts)?
>
> I find it very comfortable to have patches separated in the debian
> directory. It is true that SVN can do a good job at patching things,
> but I also find one diff.gz very uncomfortable when separating atomic
> patches. True, they can be reverted if committed atomically, but
> removing a plain patch file when upstream has merged or is no longer
> needed seems more intuitive and _I_ feel is more clean.
Sure, this seems to be common practice in many debian packages. After
rereading my post, I see that I wrote a perhaps too strong opinion about
patch helpers. Indeed, I would prefer to replace this functionality with
an SCM, but I see as well that the current packaging tools (dpkg source
format v1, svn, et al) don't support this approach enough to be a full
replacement. [1]
Long story short: I'd appreciate if it all would be possible to delegate
all packaging issues to a single tool, but obviously we are not there
yet. Having debian/patches as helper for this shortcoming is okay for me
as well.
My strong opposition remains the mergeOnUpstream mode...
> But all is adjustable to each's taste :)
Jepp, at least, it should be.
[1] sidenote: I'm looking forward to an working implementation of the
dpkg-source format 2.0 (sometimes called 'wig and pen' format), and
suitable helper tools managing these patches. Scott James Remnant seems
to have some great ideas on this area...
Reply to: