couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <robert.new...@gmail.com>
Subject Re: Apache Maven/Maven repo (Re: Dependencies in SVN)
Date Tue, 11 Aug 2009 12:28:30 GMT
Having a series of patches that apply to pristine upstream source is
also how Debian and Ubuntu packages are developed. As the changes are
fixed upstream, you drop the patch files, it's trivial to see how
patched you are from upstream, etc.

For myself, I never use the subversion repo, I clone from the git
mirror. Having to look in a separate vendor location in svn (which is
how they recommend vendor branches are managed) seems more painful
than the patch-files-in-a-directory approach.

On Tue, Aug 11, 2009 at 12:23 PM, Paul Davis<paul.joseph.davis@gmail.com> wrote:
>> I don't think keeping patches in a directory makes much sense, just apply
>> them to the copy of the vendor code in trunk. Subversion keeps track of
>> what's changed, being a version control system ;)
>
> Some things come to mind:
>
> 1. Having a directory of the patches we apply is for people that
> aren't familiar with the source or history of that code in our
> repository. For instance, my initial instinct to find the diff was to
> get trunk and then run a diff across the files outside of SVN to see
> what was different. I didn't even know the vendor branch existed until
> poking around after seeing that SVN link.
>
> 2. Hopefully, it'd make upgrading our dependencies easier. This is
> quite subjective, but "blow away directory, copy in new files, apply
> patches" seems easier to reason about than "put new copy of dependency
> in SVN, diff the versions and apply diff on top of our patches."
> Granted I haven't actually tried writing such a script so who's to
> say.
>
> 3. Most damning against the patches as files is that generating those
> patches could be 'fun'. I'd say "make it a work flow thing" but that
> just seems like bad form. Though perhaps having an extra step would
> force us to reconsider if applying a patch downstream is worth it thus
> lowering the risk of unintentional forkage.
>
> 4. Having patches as files should make it easier to reason about what
> needs to be sent upstream.
>
> 5. Git has eaten my soul. I can't stop thinking "REBASE!" being yelled
> by the "MUNCTIONAL!" guy.
>
> Paul Davis
>

Mime
View raw message